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ABSTRACT 

The  U.S.  Army  lacks  a  single  automated  fire  support  system.  The  goal  of  Army's 
ongoing  project  of  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  is  to 
integrate  all  of  its  fire  power  under  a  single  automated  system  to  provide  an  efficient  fire 
support  in  the  battlefield.  AFATDS  is  being  implemented  using  the  language  ADA  for 
battalion  and  above  level.  The  problem  for  this  research  is  to  implement  AFATDS  for 
battalion  (just  for  technical  fire  direction)  level  and  below.  In  addition,  we  want  to  add  a 
Graphical  User  Interface  (GUI),  use  modem  software  engineering  principles  and  add 
multitasking. 

The  approach  taken  was  to  apply  object-oriented  paradigm  for  the  design  and 
development  of  the  battery  level  of  AFATDS  using  Microsoft  Windows'  operating 
environment  which  provides  (non-preemptive)  multitasking  and  a  GUI,  and  Borland  C++ 
as  the  development  tool. 

The  results  are  as  follows:  The  battery  level  software  of  AFATDS  is  implemented.  The 
GUI  provided  a  better  interface  which  facilitates  easier  training  [Ref.  17].  Multitasking 
allowed  multiple  firing  missions  to  execute  concurrently  which  was  not  possible  with  BCS. 
Object-oriented  features  of  Borland  C++  provided  60%  improvement  for  GUI  development 
than  traditional  programming  languages. 
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I.  INTRODUCTION 

A.  BACKGROUND 

The  mission  of  artillery  is  to  provide  and  coordinate  devastating  fires,  giving  the 
maneuver  commander  the  overwhelming  combat  power  to  win  decisively  and  quickly 
anywhere  and  any  time.  Modem  artillery  has  improved  its  effectiveness  using  new 
technologies  with  weapon  and  C*I  systems. 

Technology  developments,  productivity,  and  battlefield  concepts  always  force  C3l 
components  to  work  in  an  integrated  environment  to  attain  victory  in  the  warfare.  The 
current  leading  field  artillery  tactical  automated  system  essentially  based  on  TACFER.Es/ 
LTACFIREs  which  are  battalion  level  systems.  The  sub- systems  of  a  TACFIRE/ 
LTACFIRE  are  Battery  Computer  Systems  (BCSs)  and  various  interfaces.  It  is  an  isolated 
system  from  other  automated  systems  and  services.  Next  step  is  to  integrate  all  the  tactical 
data  systems  of  the  army,  namely  Army  Command  and  Control  System  (ACCS).  Field 
Artillery  Tactical  Data  System  will  be  the  subsystem  of  ACCS. 

Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  which  is  an  ongoing 
project  being  a  sub  system  of  ACCS  is  aimed  to  realize  artillery  portion  of  the  integration. 
Since  AFATDS  had  not  been  fielded  yet,  the  concept  of  FATDS  is  preferred  for  the  same 
scope  of  AFATDS  for  this  thesis  research.  This  integration  will  provide: 

•  Centralized  database  which  aims  dumping  databases  to  other  computers  to  provide 
backup,  exchanging  data  between  relevant  nodes  and  reducing  data  redundancy. 

•  Faster  fire  support. 

•  Saving  resources. 

Field  Artillery  Tactical  Data  System  (FATDS)  is  composed  of  several  layers  and 
independent  interfaces.  Layers  are: 

•  Battery  level 

•  Battalion  level 


•  Corps  level 

Interfaces  are: 

•  Digital  message  devices 

•  Screens 

No  matter  how  modern  armies  prepare  themselves  for  future  conflicts,  there  will  be 
always  surprises  and  unconditional  requirements.  Reprogrammability  of  automated 
systems  provides  flexibility  to  new  requirements  of  a  battlefield.  At  this  point  software  part 
of  automated  systems  needs  programming  paradigms  which  provide  high  degree  of 
software  engineering  goals  which  are:  [Ref.21:  p.65] 

•  Modifiability:  The  software  system  should  be  easily  modifiable  without  causing  other 
errors  or  complexity. 

•  Efficiency:  The  software  system  should  operate  using  the  set  of  available  resources, 
which  are  time  and  space,  in  an  optimal  manner. 

•  Reliability:  The  software  system  should  operate  for  long  periods  of  time  without  human 
intervention. 

•  Understandability:  It  is  essential  for  modification  and  project  management  because  of 
the  need  for  coordination. 

In  addition  to  those  goals  software  developers  have  been  experimenting  with  various 
methodologies  to  achieve  some  of  the  following  goals:  [Ref.18:  p.  16] 

•  Precise  specification  of  the  design. 

•  Shorter  code  development  phase. 

•  Easier  development  of  code. 

•  Reusability  of  code. 

1.     Advanced  Field  Artillery  Tactical  Data  System 

AFATDS  is  an  ongoing  project  for  total  fire  support  system  for  U.S.  Army,  with 
its  fielding  in  FY '95.  AFATDS  will  align  targets  with  fire  units  and  munitions  and  help 
manage  survey  and  meteorological  operations,  movement  and  positioning  and  process  of 
managing  logistics.  AFATDS  will  take  into  account  all  available  fire  support  means,  to 
include  attack  helicopters,  tactical  air,  naval  gunfire  and  offensive  electronic  warfare.  It 
will  employ  sophisticated  routines  to  recommend  the  right  systems  for  the  targets  under 


analysis  and  facilitate  the  synergistic  integration  of  efforts.  The  heart  of  AFATDS' 
development  is  software. 

The  heart  of  AFATDS'  development  has  been  the  software.  The  first  step  in  the 
AFATDS  program  was  to  establish  the  command  and  control  functions  of  the  fire 
support  system,  a  detailed  analysis  that  identified  the  inputs,  the  processes  and  the 
outputs.  The  results  of  this  analysis  have  driven  the  AFATDS  software.  [Ref.23:  p. 39] 

Major  advantages  of  AFATDS  in  terms  of  software  and  hardware  are  seen  as: 
[Ref.23:  p.39-41] 

Easy  upgrades 

No  more  Mutual  Support  Units  (MSUs) 

Comprehensive  Functionality 

Interoperability 

No  AFATDS  military  occupational  speciality  (MOS)  necessary 

Common  hardware  Army-wide 

Large  screen  display 

No  more  dedicated  shelters 

Fire  Support  Elements  (FSEs)  linked  from  battalion  through  corps 

Lab-Top  computers  for  Fire  Support  Officers  (FSOs)  and  commanders 

A  key  aspect  of  AFATDS  software  will  be  its  interoperability.  As  a  component  of 
ACCS,  AFATDS  will  interface  with  maneuver,  intelligence,  air  defence  and  combat 
service  support  systems.  It  is  also  being  designed  to  interface  with  the  Air  Force  and  Marine 
automated  systems  and  with  the  German  (Adler)  and  British  (BATES)  systems.  These 
interfaces  will  significantly  enhance  the  total  integration  of  the  joint  and  combined  team. 
[Ref.23:  p.40] 

AFATDS  has  a  distributed  database  architecture.  The  database  of  each  AFATDS 
node  will  be  maintained  continually  with  the  latest  information. 

To  maintain  a  full  integration,  portability  and  easy  maintenance,  AFATDS  is 
using  DoD's  standard  programming  language,  ADA.  AFATDS  is  conceptually  evaluated 


in  1989  and  scheduled  to  be  completed  in  FY' 93  with  fielding  to  the  total  force  scheduled 
forFY'95. 

2.  Battery  Computer  System 

BCS  is  defined  as  follows: 

An  automated  data  processing  system  located  in  the  firing  battery.  It  consist  of  three 
major  components:  the  battery  computer  unit,  the  power  distribution  unit,  and  1  to  12 
gun  display  units.  It  is  used  to  compute  accurate  firing  data  and  as  digital 
communications  interface.  [Ref.10:  Glossary-2] 

3.  Motivation  for  Object-Oriented  Approach 

My  motivation  for  0-0  approach  in  general: 

•  Object-oriented  approaches  encourages  the  use  of  modern  software  engineering 
technology. 

•  Object-oriented  approaches  promote  and  facilitate  software  reusability. 

•  Object-oriented  approaches  facilitate  interoperability. 

•  When  done  well,  object-oriented  approaches  produce  solution  which  closely  resemble 
the  original  problem. 

•  When  done  well,  object-oriented  approaches  result  in  software  which  is  easily 
modified,  extended,  and  maintained. 

•  Object-orientation  improves  traceability. 

•  Object-orientation  improves  the  conceptual  integrity  of  both  the  process  and  the 
product. 

B.  OBJECTIVES 

The  objective  of  this  thesis  is  to  create  the  battery  level  software  of  Field  Artillery 
Tactical  Data  System  analyzing  the  benefits  of  object-oriented  implementation  of  both 
programming  and  database  of  the  project  in  an  environment  which  provides  multitasking 
and  graphical  user  interface. 

C.  ORGANIZATION 

Chapters  are  organized  into  two  groups:  Programming  language  and  database.  Chapter 
II  evaluates  Object-Oriented  Programming  development  languages  and  tools  briefly. 


Chapter  IE  addresses  the  design  features  of  programming  phase.  Chapter  IV  is  a 
comparison  of  the  Object-Oriented  language  implementation  of  subject  vs.  conventional 
programming  languages.  Chapter  V  evaluates  the  possible  database  management  options 
for  FATDS.  Chapter  VI  addresses  the  design  of  the  selected  database  management  option. 
Conclusions  and  future  works  on  FATDS  are  summarized  in  Chapter  VII. 


n.  THE  PROGRAMMING  ENVIRONMENT,  LANGUAGE  AND  APPLICAITON 

DEVELOPMENT  TOOLS  FOR  FATDS 


The  concept  of  Object-Orientation  may  not  give  any  idea  about  its  performance  over 
other  paradigms  without  considering  programming  environment,  language  and  application 

development  tools.1  For  this  research  I  have  chosen  PC-based  Microsoft  Windows  3.1  as 
the  programming  environment,  C++  as  the  Object-Oriented  Language  (OOL),  and  Borland 
C++  &  Application  Framework  as  the  application  development  tools.  Since  the  purpose  of 
this  research  is  to  focus  on  the  programming  performance  benefits  of  object-oriented 
implementation,  the  best  selection  of  those  elements  is  not  discussed. 

Object-Oriented  Design  (OOD)  and  Object-Oriented  Analysis  (OOA)  of  FATDS  will 
be  discussed  on  the  next  chapter.  Following  sections  discuss  the  characteristic  of  the 
selected  elements. 

A.      PROGRAMMING  ENVIRONMENT 

When  it  comes  to  portability  issue  of  a  software,  there  are  questions  to  be  answered 
about  programming  environment.  What  will  the  application  be  used  for?  What  kind  of 
terminals  will  be  used?  Who  will  be  the  users?  Which  operating  system  will  the  application 
work  on?  What  kind  of  devices  will  the  application  work  with?  Will  the  application  work 
stand-alone  or  in  networked  environment?  Does  the  application  have  to  work  with 
heterogenous  subsystems  in  an  network?  There  are  many  questions  that  a  programmer 
faces  with.  I  have  taken  PCs  as  the  main  hardware  unit.  Table  1  displays  the  system 
requirements  of  the  O-O  FATDS.  The  reasons  for  selections  this  environment  are: 

•  In  addition  to  technologic  developments,  economical  and  administrative  obligations 
makes  all  the  uniform  systems  heterogenous.  Especially  huge  systems  do  not  tend  to 
keep  themselves  uniform.  PCs  are  unique  examples  to  represent  the  variety  of  users, 
hardwares  and  software.  Though  its  heterogeneous  structure  creates  some  problems  - 
like  training,  hardware,  software  maintenance,  either  single  or  in  a  networked  media 


1.  When  an  object-oriented  system  is  under  construction,  the  architecture  is  foremost  in  impor- 
tance, just  as  it  is  in  all  other  engineering  disciplines.  The  development  process  is  adapted  to  the 
architecture,  and  the  tools  are  adapted  to  the  process.  [Ref.15:  p.26] 


PCs  are  forcing  companies  to  pay  more  attention  to  them.  PCs  word  is  developing  with 
its  new  features  and  object-orientation  is  claimed  for  being  familiar  with  these 
complexity. 

•  PCs  are  more  available  computers  to  ordinary  people.  This  means  more  people  are 
familiar  with  PCs  (which  is  important  from  the  user's  train  point  of  view)  and  there  are 
sophisticated  application  tools  for  PCs  too. 

•  Its  software  and  hardware  are  more  economical  than  work  stations. 

•  This  selection  satisfies  the  objective  of  this  research. 

TABLE  1:  SYSTEM  REQUIREMENTS  OF  0-0  FATDS 


Application 
Development,^ 

Application 
developmentoptjmai 

CPU 

IBM-386 

IBM-486 

Display 

VGA,  2  color 

SVGA,  256  color 

Sound 

- 

- 

Operation  System 

MS-DOS  5.0  &  MS- 
Windows  3.1 

MS-DOS  5.0  &  MS- 
Windows  3.1 

Memory 

2  MB  RAM 

8  MB  RAM 

Hard  Disk  Space 

80  MB 

120  MB 

1.  Hardware  Basics 

Hardware  capabilities  may  boost  the  performance  of  the  application,  but  there  is 
no  direct  relation  with  the  programming  style  for  this  research.  Board,  CPU,  caching, 
display  and  other  I/O  devices  have  direct  relations  with  either  operating  system  or 
application  requirements. 

2.  Windows  Basics 


The  general  structure  of  Windows  programming  naturally  fits  the  OOP  style. 
Everything  on  the  screen  is  defined  as  a  window,  because  each  object  has  to  have  some 
common  features.  Each  window  inherits  some  of  its  features  from  other  windows  and  add 
some  specific  ones.  The  data  goes  with  a  window  is  encapsulated  into  the  window  object. 


Window  objects  are  polymorphic,  they  can  all  receive  common  messages  and  take  action 
that  is  appropriate  for  that  window.  [Ref.25:  p.4] 

a.    The  GUI 

Does  a  user,  who  is  supposed  to  use  a  computer,  have  to  learn  what  the 
computer  is?  Or,  should  the  computer  be  designed  regarding  a  specified  user  group? 
Practically  both  questions  have  positive  answers.  Needs  and  technology  determine  each  of 
its  ratio  in  an  application. 

Most  computer  users  are  familiar  with  Windows'  GUI  and  all  Windows 
applications  have  consistent  interface.  Consistency  is  one  of  the  important  factors  which 
helps  a  user  to  adopt  a  new  application  in  shorter  time. 

Though  every  environment  provides  different  GUI  in  different  degrees  of 
graphicism  Windows  provides  all  the  basic  GUI  tools.  These  are  the  most  common 
graphical  elements: 

•  Icons 

•  Fonts  and  text  formatting 

•  Charts  and  graphics 

•  Menus 

One  of  the  graphical  elements  of  Windows  Application  Interface  (API)  is 

controls  which  represents  an  event  or  information  source  for  events.  Controls  are  mainly 
used  for  user  input.  The  leading  feature  of  controls  is  to  make  the  user  remember  some 
information  but  not  to  memorize  for  recalling.  The  controls  are: 

•  Buttons 

•  Check  boxes 

•  Combo  boxes 

•  Static/dynamic  edit  fields 

•  Radio  buttons 

•  Custom  controls 

There  are  high  level  graphical  elements  too: 

•  Drag-and-drop  mechanism 

•  Hot  spots  in  text  or  graphics  to  do  something  when  selected. 


Those  were  the  just  the  elements  of  Windows  GUI.  The  problem  is  to  produce 
something  that  the  user  will  understand  and  use  it  easily. 

b.  Event-Driven  Applications 

The  only  communication  link  between  a  user  and  a  terminal  is  Input  /  Output 
(I/O)  actions.  Procedural  interfaces  provide  I/O  in  either  command  line  or  question-and- 
answer  form.  In  either  case,  the  application  gets  some  input,  goes  off  to  process  it,  and 
produces  output.  The  application  is  the  boss,  and  the  user  acts  as  an  intelligent  database 
server.  Menu-driven  applications  takes  some  database  burden  of  the  user.  [Ref.17:  p. 39] 

Event-driven  applications  act  on  events  coming  from  a  variety  of  sources. 
The  events  may  come  from  controls  that  the  user  can  activate,  from  other  programs,  or  from 
devices  such  as  the  clock  or  communications  port. 

Event-driven  applications  are  not  specific  only  to  Windows,  but  almost  all 
Windows  applications  are  based  on  this  style.  Event-driven  programming  brings  a  different 
approach  to  the  design  and  implementation  of  an  application.  Events  leads  the  way,  so 
establishing  a  GUI  generally  is  the  first  phase  of  implementation.  Just  a  GUI,  without  a  real 
code  behind  it,  serves  as  a  prototype  of  the  application.  This  eliminates  other  third  party 
tools  for  rapid  code  prototyping. 

c.  Multitasking 

Windows  3.1  provides  a  non-preemptive  multitasking  environment.  This 
feature  is  one  of  the  key  factor  for  the  end-user.  The  user  can  run  more  than  one  application 
simultaneously. 

d.  Device  Independence 

This  feature  is  important  for  both  user  and  programmer.  The  device 
dependency  is  hidden  away  in  the  Windows'  Graphics  Device  Interface  (GDI)  and  deice 
drivers  that  are  either  bundled  with  the  retail  Windows  or  supplied  by  the  device 


manufacturer.  Windows  program  developers  can  ignore  about  devices,  they  know  that  their 
application  will  work  with  all  the  devices  that  are  introduced  to  Windows. 

For  programmers  in  non- Windows  environment,  program  output  can  be  the  most 
challenging  task  of  the  entire  application.  Idiosyncrasies  of  a  wide  variety  of  devices 
must  be  discovered,  resolved,  and  properly  handled  in  the  code.  For  small  developers, 
just  obtaining  the  necessary  manuals  and  use  of  devices  for  testing  can  prohibitively 
expensive  Under  Windows,  all  these  problems  simply  goes  away.[Ref.l9:  p.78] 

e.    Elements  of  a  Windows  Application 

A  typical  Windows  applications  has  these  elements:  A  main  window  contains 
a  title  bar,  menu  and  a  client  area.  The  client  area  serves  as  a  canvas  that  the  application  can 
draw  on.  Main  window  may  have  child  windows.  Child  window  looks  sometimes  as  a 
control  or  sometimes  another  client  region.  Dialog  boxes  are  for  either  information  display 
or  input  purposes.  Dialog  boxes  contain  a  number  of  controls,  such  as  buttons,  radio  boxes, 
etc. 

/.     Dynamic  Link  Libraries  (DLL) 

DLLs  are  one  of  the  advanced  features  of  Windows.  Normally  most  functions 
have  been  statically  linked  to  applications.  When  a  library  or  object  code  is  used  the 
executable  versions  of  the  functions  contained  in  the  code  are  brought  in  to  executable  file. 
[Ref.20:  p. 48]  Since  this  is  a  static  linking,  multiple  versions  of  the  same  function  may  exist 
in  the  executable  file.  Any  modification  on  the  library  functions  require  relinking  of  the 
application.  So  the  whole  application  is  replaced. 

Dynamic  linking  occurs  at  run-time.  Application  is  just  introduced  to  the 
function  and  in  which.  DLL  file  its  implementation  is  placed.  The  executable  file  does  not 
carry  the  object  code.  When  the  executing  program  makes  a  call  to  a  dynamic  link  function, 
Windows  checks  to  see  whether  the  function  is  already  in  memory.  If  it  is  in  memory 
Windows  increases  the  in-use  counter  for  this  library  by  one  and  passes  execution  to  the 
new  memory  location.  If  the  function  is  not  already  in  memory,  Windows  tries  to  find  a  file, 
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with  a  .DLL  extension,  that  contains  the  desired  function.  Windows  then  loads  the  function 
into  memory.  [Ref.20:  p.49] 

The  only  disadvantage  of  DLLs  is  that  .DLL  files  should  be  ported  with  the 
application  while  the  advantages  of  DLLs  are: 

•  Downsize  the  executable  code  size  and  compile-link  time.  E.g.,  OFTRE.EXE  file  was 
more  than  400K  Ion  before  using  .DLLs,  and  it  become  almost  150K  long  executable 
file. 

•  Provide  the  application  to  run  on  computers  that  have  a  limited  amount  of  memory. 

•  Ease  the  maintenance  of  the  code.  When  a  DLL  file  is  updated,  it  is  enough  to  replace 
that  .DLL  file  without  linking  the  whole  code. 

•  Make  interchangeable  modules. [Ref. 25:  p.66] 
B.      PROGRAMMING  LANGUAGE 

I  have  selected  C++  as  an  OOPL.  It  is  not  the  only  OOPL,  but  it  is  one  of  the  OOPLs 
that  supports  all  the  0-0  features.  One  of  the  leading  reasons  which  makes  me  select  C++ 
is  its  commercially  availability. 

For  better  or  worse,  the  real  winner  today  is  C++,  which  attracts  large  groups  of 
programmers  at  the  largest  companies  and  is  used  on  thousands  of  projects  in  industry. 
[Ref.l5:p.26] 

Stroustrup  lists  the  language  features  of  C++  as: 

C-based,  object-oriented  extension  of  C. 

Class  concept  and  class-based  object-oriented  paradigm. 

Data  abstraction  and  data  encapsulation  facilities. 

Mechanism  for  data  abstraction  hierarchies. 

Strongly  typed. 

Function  and  operator  overloading. 

User-controlled  memory  management. 

Facilities  modeling  multiple  inheritance. 

Support  polymorphism. 

Type-safe  linkages. 

Abstract  classes. 

Exception  handling  mechanism. 

Used  for  general  purpose  applications  as  well  as  simulations  development. 
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•  Can  be  use  to  model  conceptual  solutions. 
C.     APPLICATION  DEVELOPMENT  TOOLS 

Borland  provides  all  the  tools  that  is  necessary  to  produce  Windows  programs. 

1.  Application  Development  tools 

Borland  C++  3.1  and  Application  Framework  has  the  following  tools: 

An  ANSI  C  and  C++  global  optimizing  compiler 

A  DOS  protected-mode  interface  (DPMI)  compiler  and  programmer's  platform 

A  Windows-base  integrated  development  environment  (IDE) 

A  graphical  source  browser  (ObjectBrowser) 

A  utility  for  tracking  Windows  messages  (WinSight) 

A  debugger  for  DOS  and  Windows  applications  (Turbo  debugger) 

A  profiler  for  DOS  and  Windows  (Turbo  Profiler) 

The  Turbo  Assembler 

The  Resource  Workshop 

A    library    of    C++    classes    to    simplify    Windows    application    development 
(ObjectWindows) 

The  Easy  Win  library  for  porting  DOS  programs  to  Windows 

The  Turbo  Vission  application  framework  for  DOS  applications 

Source  code  to  the  runtime  library 

2.  Language 

Borland  compiler  runs  in  protected  mode,  so  large  programs  and  libraries  do  not 
require  extensive  swapping.  Precompiled  header  are  supported.  Because  the  headers  for 
Windows  programs  tend  to  be  quite  large  (windows.h  alone  is  over  120K),  this  Borland 
C++  feature  can  increase  compile  times  by  a  factor  of  ten.[Ref.l9:  p.xviii][Ref.25:  p. 5] 

Borland  IDE  editor  provides  to  open  multifiles  simultaneously  as  well  as  large 
files. 
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m.  OBJECT-ORIENTED  PROGRAMMING  DESIGN  OF  FATDS 

A.     INTRODUCTION 

Object-oriented  programming  should  follow  Object-Oriented  Analysis  (OOA)  and 
Object-Oriented  Design  (OOD).  Though  0-0  paradigm  goes  back  two  decades,  OOA  and 
OOD  methodologies  are  not  mature  enough.  [Ref.14:  p.22]  Discussions  are  still  continuing 
about  a  perfect  methodology  for  both  OOA  and  OOD.  The  goal  of  OOA  is  still  the  same: 
the  development  of  an  accurate  and  complete  representation  of  the  problem  domain. 
[Ref.14:  p. 26]  The  problem  is  that  there  is  no  standard  OOA  methodology.  I  have  selected 
Coad  &  Yourdon  OOA  [Ref.6]  and  Booch  OOD  [Ref.4]  to  build  basis  for  0-0 
methodologies  of  this  research. 

1.      Coad  and  Yourdon  OOA 

This  model  defines  the  problem  domain  in  five  consecutive  steps  where  each  step 
builds  on  the  previous  step.  The  steps  are:  [Ref.14:  p. 27] 

•  Define  objects  and  classes:  Look  for  structures,  other  systems,  devices,  events,  roles, 
operational  procedures,  sites,  and  organizational  units. 

•  Define  structures:  Look  for  relationship  between  classes  and  represent  them  as  either 
general-to-specific  structures. 

•  Define  subject  areas:  Examine  top  level  objectives  within  whole-to-part  hierarchies  and 
mark  these  as  candidate  subject  areas.  Refine  subject  areas  to  minimize 
interdependencies  between  subjects. 

•  Define  attributes:  Identify  the  atomic  characteristics  of  objects  as  attributes  of  the 
object.  Also  look  for  associative  relationships  between  objects  and  determine  the 
cardinality  of  those  relationships. 

•  Define  services:  For  each  class  and  object,  identify  all  the  services  it  performs,  either 
on  its  own  behalf  or  for  the  benefit  of  other  classes  and  objects. 

Coad  and  Yourdon  uses  the  following  tools  for  OOA: 

•  Class  and  object  diagram 

•  Object  state  diagram 

•  Service  chart 
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2.  Booch  OOD 

Booch  is  the  pioneer  of  OOD.  Booch 's  methodology  was  originally  ADA 
language  specific,  but  he  adopted  his  methodology  to  0-0  completely.  He  recommends  not 
a  specific  ordering  of  analysis  plus  design  phases.  The  strategy  should  be  "analyze  a  little, 
design  a  little"  [Ref.4:  p.201].  Because  there  is  no  certain  border  between  analysis  and 
design  of  a  problem  to  jump  from  one  to  another.  Design  process  should  be  worked  with 
iteratively  and  incrementally,  augmenting  formal  diagrams  with  informal  techniques 
appropriate  to  the  problem  at  hand.  Booch's  four  major  design  steps  are  [Ref.14:  p. 32]: 

•  Identify  classes  and  objects:  Identify  key  abstractions  in  the  problem  space  and  label 
them  as  candidate  classes  and  objects. 

•  Identify  the  semantics  of  classes  and  objects:  Establish  the  meaning  of  the  classes  and 
objects  identified  in  the  previous  step  using  a  variety  of  techniques ,  including  creating 
"scripts"  that  define  the  life  cycles  of  each  object  from  creation  to  destruction. 

•  Identify  relationships  between  classes  and  objects:  Establish  class  and  object 
interactions,  such  as  patterns  of  inheritance  among  classes  and  pattern  of  cooperation 
among  classes  and  patterns  of  cooperation  among  objects.  This  step  also  captures 
visibility  decisions  among  classes  and  objects. 

•  Implement  classes  and  objects:  Construct  detailed  internal  views  of  classes  and  objects, 
including  definitions  of  their  of  their  various  behaviors  (services).  Also,  allocate 
objects  and  classes  to  modules. 

Booch  uses  the  following  tools  for  OOD: 

•  Class  diagrams  and  class  templates 

•  Object  diagrams  and  timing  diagrams 

•  state-transitions  diagrams 

•  operation  templates 

•  module  diagrams  and  templates 

•  process  diagrams  and  templates 

3.  My  OOA  and  OOD  Strategy 

As  it  is  indicated  above  I  carried  out  analysis  and  design  together.  The  reasons  are: 

•  There  is  no  distinct  border  between  analysis  and  design.  Switching  to  design  to  late  may 
cause  waste  of  resources  while  switching  too  early  may  cause  not  to  identify  the 
problem.  It  is  more  flexible  to  do  them  together. 

•  The  design  may  not  reflect  the  capabilities  of  the  system  environment  or  the 
requirements  of  the  user  completely.  Instead  of  using  external  software  prototyping 
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tools,  GUI-based  prototyping  which  could  be  performed  at  various  steps  of  system 
development,  provides  realistic  and  early  evolution  of  the  design.  Each  time  after 
receiving  feed-backs  from  the  consumer,  it  could  be  necessary  to  modify  the  analysis 
again. 

•  There  are  diverse  design  options  for  the  project.  Not  all  the  design  options  are  derived 
from  the  analysis.  At  a  point  in  the  project  it  would  be  necessary  to  modify  the  design 
and  the  analysis  process  as  well. 

•  There  may  appear  some  constraints  and  force  to  change  to  alternate  designs.  E.g.,  size 
of  code  may  force  the  system  hardware's  memory  limitations. 

Above  conditions  are  valid  not  only  for  0-0  methodologies,  but  also  for  non- 
object-oriented  ones.  After  evolution  of  a  system,  if  a  modification  is  required,  then  it  will 
be  necessary: 

•  To  add  a/some  new  part(s)  into  the  system  and/or, 

•  To  throw  away  a/some  part(s)  of  the  system  and/or, 

•  To  modify  a/some  part(s)  of  the  system 

Object-oriented  systems  adds  another  option  for  creation  or  modification  of  a 
system:  Reuse.  At  the  beginning  of  a  large  project  development  or  on  small  projects  the  role 
of  reusing  may  not  be  so  important,  but  during  the  development  of  phase  and  for  large 
scaled  projects  reusing  begins  to  save  resources.  Assuming  that  old  components  of  the 
system  are  well  tested,  other  objects  which  are  created  by  inheriting  those  old  objects  are 
most  likely  be  trusted  objects.  It  will  take  shorter  time  to  test  new  objects. 

First  product  after  a  brief  analysis  was  the  GUI  of  the  project.  The  design  of  GUI 
is  an  application-independent  technology  for  which  a  number  of  useful  libraries  of  reusable 
software  components  have  been  developed.  So,  GUI's  development  was  faster  than  the 
applications.  FIGURE  1  on  page  16  show  the  cycles  for  O-O  FATDS  project  development. 
This  cycle  is  named  as  Model-Based  Project  Development  Cycle  (MBPDC).  The 
product(s)  is  always  tested  with  the  real-life  requirements  during  the  development  cycle, 
even  though  the  product(s)  is  not  a  complete  one  during  the  process.  First  analysis  helps  to 
form  classes  and  objects  to  create  the  first  form  of  the  product  which  is  just  the  GUI. 
Modeling  and  testing  begins  with  this  GUI  which  serves  as  a  prototype.  This  is  more  than 
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a  usual  prototype  which  simulates  a  real-life  application,  but  it  is  the  real-life  application. 
Modeling  leads  the  design,  so  the  analysis. 


Figure  1:  Model -based  project  development  cycle  for  0-0  FATDS 


There  is  always  a  working  model.  Functionality  of  the  model  is  limited  during  the 
development  cycle  and  it  completely  matures  4t  the  end  of  the  MBPDC. 

The  nature  of  event-driven  programming  and  its  compatibility  with  OOP  helps  to 
establish  separate  or  independent  event  modules.  This  event  inter-independency  and 
reusing  makes  the  modification  easier  at  any  time  of  MBPDC. 

4.     Naming  Conventions 

For  a  more  readable  code  I  have  used  long  meaningful  names  for  variables, 
enumeration  types,  classes,  and  objects  etc.  E.g.,  SubFireCallWndCls  and  RadioGrid. 
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I  have  also  embedded  small  identifiers  into  the  names  to  distinguish  them  from 
others.  In  addition,  I  named  an  instance  of  a  type  or  class  almost  the  same  with  its 
instantiator,  e.g.,  SubFireCalTWndCls  is  a  class  type  and  SubFireCallWnd  is  instance  of 
that  class.  Table  2  on  page  17  displays  a  list  of  embedded  codes  which  are  used  for  naming 
in  this  research. 

TABLE  2:  EMBEDDED  CODES  FOR  NAMING 


*Cls 

Class  defination 

*DlgCls 

Dialog  window  class  defination 

*Dlg 

Dialog  object 

*WndCls 

Window  class  defination 

*Wnd 

Window  object 

Button* 

Button  control  object 

Check* 

Check  box  control  object 

Combo* 

Combo  box  control  object 

Edit* 

Edit  control  object 

List* 

List  box  control  object 

Radio* 

Radio  box  control  object 

h* 

Any  kind  of  object  handler 

ID_* 

Identifier  for  window  objects 

*Type 

Enumeration  type  definition 

B.      ANALYSIS 


1.     FATDS  System  Requirements 


FIGURE  2  on  page  18  displays  a  block  diagram  for  Firing  Support  (FS)  portion 
of  FATDS.  The  basic  function  of  the  system  is  to  make  the  guns  fire  with  computed  data 
against  the  targets  on  the  battlefield  which  are  asked  from  artillery  to  be  destroyed. 
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Target  acquisition  elements 


Target  info 
Gun  and 
ammo 
status 


Target  info 
Firing  table 
Met  message 


Gun  and  ammo  status 
Firing  reports 


Fire  Direction  Centers 


Command  and  Control  Centers 


Target  acq.  info 
Met  messages 
Surveys 


Fire  commands 
Fire  Orders 


Met  messages 
Surveys 


Firing  reports 
Gun  and  ammo  status 


(Survey  elements) 


Fire  commands 


Guns 


Figure  2:  Block  diagram  for  Field  Artillery  Tactical  Data  System  /  FS 

Each  of  the  block  elements  could  represent  more  than  one  of  that  element  and  in 
diverse  organizational  structures.  The  automation  of  the  each  structure  may  differ  too. 
Regarding  the  communication  tools  of  any  kind  and  battlefield  irregularity,  the  system 
should  keep  to  work  with  acceptable  functionality.  The  major  system  elements  are: 

♦  Guns:  They  are  organized  in  platoons,  batteries  or  battalions  as  basic  firing  units.  The 
number  of  guns  and  models  of  them  vary. 

•  Fire  direction  centers:  The  element  of  a  command  post  consisting  of  gunnery  and 
communication  personnel  and  equipment  by  means  of  which  the  commander  exercises 
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fire  direction  and/ or  fire  control.  The  fire  direction  center  receives  target  intelligence 
and  requests  for  fire  and  translates  them  into  appropriate  fire  direction  [Ref.J  1 :  p.G- 
8].  FDCs  are  functional  at  platoon,  battery  and/ or  battalion  levels. 

•  Target  acquisition  elements:  There  are  various  target  acquisition  elements.  FA 
battalion  S2,  targeting  officer,  fire  support  team,  aerial  fire  support  observers,  combat 
observation/ lasing  team,  survey  platoon,  weapons-location  radar,  moving-target- 
locating  radar  and  electronic  warfare  are  all  the  elements  for  target  acquisition.  / Ref. 7: 
P-S-U 

•  Command  and  control  elements:  From  Fire  Direction  Officer  (FDO)  at  platoon  I 
battery  level  to  higher  tactical  headquarter  who  plans  and  controls  the  fire  are  included 
in  this  block.  Their  role  is  tactical  rather  than  technical.  These  elements  make  decisions 
about  "Who  will  fire?" ,  "Which  target(s)  will  be  fired?" ,  "What  kind  of weapon(s)  & 
ammunition(s)  combination  will  be  formed?" ,  "When  will  be  the  firing  time?  Different 
levels  of  command  may  have  different  control  responsibilities  on  various  operations. 

•  Survey  elements:  These  are  technical  elements  too.  Survey  elements  provides  met 
messages,  target  intelligence,  and  land  survey  support  for  the  FDC  and  command 
control  elements. 

•  Database:  Local  or  centrally  located,  distributed  or  single  database  system  is  the  main 
information  source  of  the  system.  To  avoid  waste  of  resources,  central  databases  are 
encouraged. 

•  Timer:  This  is  just  a  control  element  which  sets  the  timed  fires  or  other  events.  All  the 
elements  should  follow  a  central  time  function  for  synchronization. 

The  following  inputs  exists: 

Fire  call 

Fire  order 

Fire  commands 

Fire  orders 

Firing  reports 

Firing  table 

Gun  and  ammo  status 

Message  to  observer  (MTO) 

Met  messages 

Subsequent  fire  calls 

Status  reports 

Subsequent  fire  call 

Surveys 

Target  acquisition 

Target  info 

Target  lists 

Target  update 
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•  Time 

2.     Defining  the  Boundaries  of  the  Problem 

Field  Artillery  Tactical  Data  System  is  sub-part  of  the  army's  integrated 
battlefield  automation  program.  Since  this  is  a  huge  and  sophisticated  program  this  research 
has  captured  only  Field  Artillery  (FA)  Battery  Fire  Direction  level  regarding  its  FS  portion. 
FIGURE  3  on  page  20  displays  the  block  diagram  of  battery  level  tactical  data  system  /  FS. 


Battalion  FDC  / 

Battalion  TACFIRE  /  LTACFIRE 


Observer(s) 


Survey  elements 


Firing  results 
•£un  and  ammo  status 


Time 


Timer 


Gun(s) 


Figure  3:  The  block  diagram  for  FATDS  /  FS  at  Battery  level 
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FIGURE  4  on  page  21    displays  the  block  diagram  for  battery  fire  direction 
system.  There  are  two  major  functional  units,  firing  chart  and  computation.  Firing  chart 


Observer 


Target  location  info 
Fire  calls 
Subsequent  fire  calls 


Battalion 


Target  list 


Filing  chart 


Surveys 


Survey  elements 


Chart  values  (range,  deflection) 


Timer 


Time 


Computation 


Fire  commands 


m*4  m«r.oo^  Survey  elements 
Met  messages  ' 


Firing  report 


Guns 


Figure  4:  The  block  diagram  for  battery  fire  direction  system 


holds  the  coordinates  of: 

•  Batteries  (gun  positions) 

•  Radars 

•  Observation  posts 

•  Registration  points 

•  Targets 
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•  Check  points 

Firing  chart  produces  linear  and  angular  distances  of  any  two  points,  which  are  on 
the  chart,  for  computation. 

After  having  chart  values  Computation  transfers  them  into  firing  commands  and 
sends  them  to  the  firing  elements  (guns).  Computation  reflects  its  computational  results  on 
Record  of  Fire  (ROF)  form.  Computation  produces  the  firing  commands  regarding: 

•  Time:  At  my  command,  When  ready,  Time  on  Target  (TOT). 

•  Firing  techniques:  Surveyed  firing,  copperhead  munition  firing,  nuclear  munition 
firing,  smoke  projectile  firing,  illuminating  projectile  firing,  MET+VE  technique, 
registration,  Fire  for  Effect  (FFE),  special  corrections. 

•  Firing  tactics:  Attack  of  large  targets,  target  analysis,  safety  procedures,  munition 
effects. 

•  Ballistics  (interior  and  exterior):  Nature  ofpropellant  and  projectile  movement,  muzzle 
velocity,  meteorological  conditions,  dispersion. 

3.     Defining  the  Objects  and  Classes 

Followings  are  the  classes  derived  from  the  block  diagram  of  the  system  and/or 
description  of  the  diagram  elements. 

•  Dispersion 

•  Chronometer 

•  Fire  commands 

•  Fire  Calls 

•  Subsequent  fire  calls 

•  Fire  order 

•  Message  to  observer 

•  Computation 

•  Firing  report 

•  Gun  and  ammo  status 

•  Target  database 

•  Firing  report  database 

•  Met  messages  database 

•  Guns  and  munitions  database 
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4.     Define  Subject  Areas 

Classes  are  grouped  into  two  main  subject  areas:  Firing  chart  and  firing 
computation.  Those  groups  will  be  the  basis  for  the  design  of  GUI.  The  classes,  which  have 
been  formed  so  far,  are  nothing  to  do  with  GUI  but  they  will  be  re-organized  after  the  events 
of  the  GUI  is  determined. 

C.     GRAPHICAL  USER  INTERFACE  DESIGN 

So  far  two  functional  unit  appeared.  They  will  be  named  as  OF  ire  for  firing 
computations  and  OChart  for  firing  chart  manipulations.  GUI  design  was  the  backbone  of 
the  analysis  phase.  They  have  been  accomplished  together.  Since  the  GUI  served  as  a 
prototype  of  the  final  product,  it  was  useful  determine  the  events  for  objects,  classes  and 
the  relationships  of  them. 

1.     Design  Considerations 

The  design  of  a  GUI  is  being  effected  not  only  by  the  capabilities  of  the  system's 
environment,  but  also  by  the  following  criteria. 

a.     The  User 

Since  both  OChart  and  OFire  are  specific  applications  for  a  Field  Artillery, 
the  number  of  the  users  is  limited  with  the  FA  Fire  Direction  Center  (FDC)  personnel. 
Training  requirements  are  still  one  of  the  major  issues  with  the  user.  Windows  GUI 
environment  eliminates  some  of  the  training  problems  and  add  these  features: 

•  The  user  does  not  have  to  memorize  everything.  He/she  inputs  most  of  the  data  by 
selecting,  not  by  entering.  He/she  is  not  overloaded  with  decision  making  points  at  the 
same  time,  but  he/she  is  asked  to  do  only  when  necessary. 

•  The  GUI  is  forgiving  for  the  user  decisions,  it  is  possible  to  take  decision  steps  back. 
So,  the  system  is  less  error-prone. 

•  Even  though  the  user  knows  nothing  about  Dos/Windows  or  any  other  OS  which 
operates  a  window  style  environment,  this  will  help  the  user  to  adapt  the  software  in  a 
snorter  time  than  the  command  line  style  interface.  There  is  no  certain  educational 
background  except  reading&writing. 
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b.  Consistency 

One  of  the  most  important  issues  with  GUI  is  consistency.  Each  part  of  the 
applications  should  be  consistent  with: 

•  Other  issues  of  the  user's  way  of  life:  Button  shapes  and  behaviors,  sounds  and 
graphics  for  warnings,  etc.,  should  be  consistent  with  the  user's  daily  life. 

•  Other  applications  in  that  OS  environment:  The  user  should  transfer  some  of  her/his 
experiences  from  one  application  to  other.  This  helps  to  shorthen  the  training  and 
adaptation  period,  besides  prevent  some  errors  which  are  source  from  controversies. 

c.  Screen-Layout  Issues 

Menu  system,  naming  terminology,  semantic  grouping  of  items,  fonts  and  use 
of  color  are  main  points  of  screen-layouts.  All  of  these  factors  contribute  to  success  of  a 
software,  so  the  victory. 

d.  Customizing 

To  allow  a  user  to  customize  an  application  makes  easier  to  use  that 
application  in  accordance  with  that  user's  condition  only.  To  provide  standardization  and 
easier  adaptation  of  users  to  the  applications  customization  is  not  allowed  for  OChart  and 
OFire  applications. 

e.  Input  and  Output  Devices 

Main  input  device  for  Windows  applications  is  mouse  as  well  as  keyboard. 
Voice  activated  commands  may  be  used  with  some  limitations  too.  Lessening  the  role  of 
keyboard  for  data  entry  decreases  the  training  needs  and  increases  the  performance  of  the 
application 

/.     On-Line  help  and  Tutorials 

Application  should  feed  the  user  with  necessary  information  which  is  about 
what  he/she  is  doing,  or  to  do  etc.,  at  a  time  when  he/she  needs.  Windows  allows  a  standard 
style  help  system  which  is  context-sensitive  and  topic-navigated. 
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g.    Error  Handling 

People  are  tend  to  make  errors  even  if  they  are  trained  on  that  topic.  Windows 
event-driven  environment  makes  it  easier  to  add  check  points  and  warnings  for  each 
reaction  of  the  user. 

2.  OFire 

All  the  windows  and  dialog  boxes  designed  for  the  OFire  application  are 
displayed  on  APPENDIX-D. 

3.  OChart 

All  the  windows  and  dialog  boxes  designed  for  the  OChart  application  are 
displayed  on  APPENDIX-D. 

D.     OBJECT-ORIENTED  DESIGN  (OOD) 

1.     Identify  Classes  and  Objects  and  Their  Semantics 

The  classes  have  been  formed  with  their  actual  names  and  grouped  into 
programming  modules.  Not  all  the  classes  have  been  formed  at  the  same  time  and  those 
classes  are  the  last  phase  of  the  development. 

a.     The  Classes  for  OFire 

(1)  bursts. h 

•  SheafWndCls 

•  BurstsWndCls 

(2)  button2.h 

•  Button2Cls 

(3)  command.h 

•  CommandWndCls 

•  ChronoWndCls 

•  FireCommandsWndCls 
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•  InfoWndCls 

•  SubFireCallWndCls 

(4)  fire.h 

•  FireCallDlgCls 

•  PolarWndCls 

•  ShiftWndCls 

•  GridWndCls 

•  SuppressionWndCls 

•  FireOrderDlgCls 

•  MTODlgCls 

•  SubFireCallDlgCls 

•  TOTAtTimeDlgCls 

•  TOTAfterTimeDlgCls 

(5)  globals.h 

•  ComputationCls 

(6)  report.h 

•  ReportWndCls 

•  TextWndCls 

(7)  select.h 

•  SelectionWndCls 

b.     The  Classes  for  OChart 

(1)  abslist.h 

•  genAbstractList:  Implements  an  abstract  class  of  linked  lists. 

(2)  Chart.h 

GridSetupDlgCls 

TargetSetupDlgCls 

GunSetupDlgCls 

NewEntryDlgCls 

NewFromEntryDlgCls 

GunlnputDlgCls 

TargetlnputDlgCls 

TargetDBDlgCls 

GunDBDlgCls 
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(3)  gen21ist.h 

•  genOdList 

•  genUdList 

(4)  globals.h 

•  GlobalCls 

(5)  gundb.h 

•  GunDBCls 

(6)  info.h 

•  SelectionToolCls 

•  DistanceToolCls 

•  NewToolCls 

•  NewTToolCls 

•  SearchToolCls 

•  PickToolCls 

•  InfoWndCls 

•  ToolBarWndCls 

•  CanvasWndCls 

(7)  Targetdb.h 

•  TargetDBCls 

2.     Identify  Relationship  Between  Classes  and  Objects 

FIGURE  5  on  page  28  and  FIGURE  6  on  page  29  display  the  class  relationships. 
In  those  figures  system  and  user-defined  classes  are  distinguishable.  All  the  dialog  or 
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window  classes  which  helps  to  develop  GUI,  inherit  most  of  their  behaviors  from  then- 
parent  classes. 


TOTAfterTimeDlgCIs  | 

TOTAtTimeDlgCIs 

i  TDialog    ^~ — —_ 

MTODIgCIs 

SubFireCallDlgCIs  | 

FireOrderDlgCIs 

FireCallDlgCIs 

TSreamable    r — 

TWindowsObject  I 

\ 

SheafWndCIs 

BurstsWndCIs 

WStr                        \ 

CommandWndCIs 

ChronoWndCIs 

FireCommandsWndCIs  | 

InfoWndCIs 

SubFireCallWndCIs  | 

1  VVIIIUUW      fc^. 

\V\\ 

PolarWndCIs 

ShiftWndCls 

GridWndCIs 

SuppressionWndCIs  | 

ReportWndCIs 

TextWndCIs 

Figure  5:  Class  hierarchy  for  OFire  (i) 


3.     Implement  Classes  and  Objects 

Complete  listings  of  header  files  are  provided  on  APPENDIX  A  and  APPENDIX 


B. 
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UDject                      i  MOuuie                       i  Application                     rireAppL/is 

I  wmaow                        i  ooriiroi                         iduuum                         Liuuon^uis 

DBGunCIs 

DBTargetCIs 

WParadoxRecord  1 

WParadoxTable 

WParadox Engine  | 

DBTable_F_Cls  | 

ComputationCIs  1 

Figure  6:  Class  hierarchy  for  OFire  (ii) 

E.      FILE  ORGANIZATION 

1.     File  Organization  for  C++  Windows  Programming 

FIGURE  7  on  page  30  shows  a  sample  file  organization  for  a  a  simple  C++ 
Windows  program.  Every  class  is  defined  in  a  header  file  and  its  implementation  is  placed 
in  source  files.  One  of  the  exception  to  this  rule  is  Main  file.  There  are  two  class  definitions 
for  a  main  Windows  program  and  a  main  program  function.  One  of  them  inherits  from 
TApplication  class  and  it  registers  the  instance  of  the  application  to  Windows  system.  The 
other  one  inherits  from  TWindow  or  TDialog  class  and  it  creates  a  window  for  the 
application.  The  declarations  of  those  classes  are  generally  placed  in  Main  Source  File 
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since  they  will  not  be  called  or  instantiated  by  anyone.  Only  main  program  functions 
instantiates  them  and  use  it.f 


( 

Main  Header  File 

Main  .obj  File      V^ 

Main  Source  File 

Library  Files       J 

p4    . exe  F 

-«e    i 

Class  Header  Files 

i 

> 

Class  .obj  File    j                > 

/ 

N 

Class  Source  Files 

.dll  Files 

Resource  File  (.re) 

.res  file             Y 

*\. 

Figure  7:  C++  development  file  organization  for  Windows  environment 


Main  Header  File  is  used  for  some  definitions,  and  dialog  box  class  declarations. 
If  some  objects  are  placed  in  .DLL  files,  its  header  files  are  still  kept  like  other  built-in  class 
libraries.  The  only  difference  for  their  usage  is  that,  it  should  be  told  to  the  compiler  the 
implementation  of  any  class  or  function  is  placed  in  .DLL  files.  That  specific.DLL  file  will 
only  be  searched  during  run-time. 
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Another  file  which  is  specific  to  Windows  is  resource  file.  It  is  a  text  file  and  holds 
the  resource  descriptions  of: 

•  Accelerators 

•  Bitmaps 

•  Cursors 

•  Dialog  boxes 

•  Fonts 

•  Icons 

•  Menus 

•  String  tables 

Resource  file  can  be  created  either  manually  or  with  Resource  Workshop.  It  is  not 
in  a  specific  language,  though  it  is  in  a  special  text  format.  Borland  C++  compiler  compiles 
it  with  a  special  compiler  and  links  it  to  the  code.  All  the  resource  code  is  placed  in  the 
executable  file  in  separate  modules.  This  allows  the  Resource  Workshop  application  to 
open  and  modify  the  resources  of  an  application  without  disturbing  the  executable's 
functionality.  Eliminating  compile  and  linking  efforts,  this  makes  the  maintenance  easier 
from  the  resource  point  of  view. 
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2.     FATDS's  File  Organization 

The  file  organization  of  FATDS  is  shown  on  FIGURE  8  on  page  32  and  FIGURE 
9  on  page  33  . 


bursts,  h 


button2.h 


command. h 


dbgun.h 


dbtarget.h 


dbtbl  f.h 


fire.h 


globals.h 


pxengine.h 


report,  h 


select. h 


paradox,  h 


pdoxeng.h 


pdoxrec.h 


pdoxtab.h 


wstr.h 


c 

fire.cpp      ^ 

c 

bursts. cpp    ^ 

c 

button2.cpp  "^ 

c 

command.cpp^ 

c 

dbgun.cpp   J 

c 

dbtarget.cpp  ^ 

c 

dbtblj.cpp  ^ 

c 

dialogs.cpp  "^ 

r 

globals.cpp  ^ 

L 

report.cpp    ^ 

C 

select.cpp     J 

fire.prj 


fire,  re 


fire.def 


55an13f.db 

55an14a.db 

55an14b.db 

55an14c.db 

55an14e.db 

55an14f.db 

55an15a.db 

55an16a.db 

55an17a.db 

55an18a.db 

guns.db 

targets.db 


fire.ini 


bwcc.dll 

paradox.dll 

pxengwin.dll 


Figure  8:  File  organization  of  FATDS  /FS  (ofire) 
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chart. h 
gen2list.h 


dbtarget.h 


dbgun.h 


abslist.h 


globals.h 


pxengine.h 


defines. h 


globals.h 


wparadox.h 


wpdoxeng.h 


wpdoxrec.h 


wpdoxtab.h 


wstr.h 


c 

chart.cpp    "} 

c 

dialogs.cpp  } 

c 

gen2list.cpp  J 

c 

gridset.cpp  ^ 

c 

info.cpp     J 

c 

dbtarget.cpp  ~~) 

c 

dbgun.cpp    ^ 

chart.prj 


chart.rc 


chart.def 


guns.db 
targets.db 


chart.sav 


bwcc.dll 


Figure  9:  File  organization  of  FATDS  /FS  (ocnart) 
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F.  DESIGN  DECISIONS  FOR  DLLs 

Borland  C++  and  Windows  both  have  limited  number  of  DLL  files.  Each  application 
adds  new  DLL  files  to  the  system.  The  more  an  application  uses  DLL  files  the  more 
performance  it  provides  to  the  user. 

DLLs,  necessary  for  out  prototype  are: 

•  Custom  controls,  e.g.,  button2. 

•  Database  engine  and  other  database  service  files  which  works  with  database  engine. 

G.  INITIALIZATION  FILES 

Some  objects  in  the  applications  may  need  to  initialize  some  of  their  attributes  before 
they  are  created  and  store  them  back,  just  after  they  are  deleted.  The  values  of  those 
attributes  should  be  stored  in  a  persistent  environment.  C++  does  not  provide  a  built-in 
database  management  system  (it  does  not  have  to)  to  store  such  values.  There  are  three 
options  to  do  that: 

•  To  use  a  separate  DBMS 

•  To  use  binary  files  using  C++'s  stream  libraries 

•  To  use  text  files  using  C++'s  stream  libraries. 

First  option  is  not  beneficial  for  such  short  amount  of  data.  It  increases  the  size  of  code 
and  implementation  time.  Binary  files  store  and  retrieve  the  objects  keeping  their 
abstraction  or  their  type. 

For  the  OChart  application,  it  runs  using  the  last  values  of  which  just  before  it  is 
closed.  E.g.,  the  user  will  probably  want  to  open  the  firing  chart  with  the  same  window  size, 
at  the  same  screen  location,  with  the  same  scale  and  customization  etc.,  as  he/she  close  it 
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for  the  last  time.  Each  object  stores  these  kinds  of  persistent  data  in  a  * .  sav  file.  One  file 
for  each  application  is  enough  and  it  should  be  binary  file. 

Some  persistent  data  which  is  useful  for  customization  should  be  stored  in  text  files 
with  * .  ini  extensions.  These  kinds  of  data  are  mostly  in  string  type  or  don't  cost  much  to 
convert  to/from  other  types.  Its  difference  from  * .  sav  files,  * .  ini  files: 

•  Can  be  edited  by  the  user  without  running  the  application  using  any  kind  of  text  editor. 

•  is  useful  to  feed  any  type  of  control,  like  combo  boxes  and  list  boxes,  with  persistent 
data.  Any  object  which  can  easily  reach  these  data  without  worrying  about  data 
structure. 
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IV.  COMPARISON  OF  OBJECT-ORIENTED  VS.  CONVENTIONAL 
PROGRAMMING  PERFORMANCES 


A.  INTRODUCTION 

As  the  need  for  the  computers  increases,  so  do  the  problem  domain  for  the  software. 
The  software  engineering  goals,  which  are  described  in  the  first  chapter,  are  sourced  from 
the  software  problem.  Some  of  the  problems  can  be  stated  as  [Ref.3:  p. 8]: 

•  Responsiveness:  Computer-based  systems  often  do  not  meet  user  needs. 

•  Reliability:  Software  often  fails. 

•  Cost:  Software  costs  are  seldom  predictably  and  are  often  perceived  as  excessive. 

•  Modifiability:  Software  maintenance  is  complex,  costly  and  error-prone. 

•  Timeliness:  Software  is  often  late  and  frequently  delivered  with  less  than-promised 
capability. 

•  Transportability:  Software  from  one  system  is  seldom  used  in  another,  even  when 
similar  functions  are  required. 

•  Efficiency:  Software  development  efforts  do  not  make  optimal  use  of  the  resources 
involved  (processing  time  and  memory  space). 

O-O  is  not  a  silver  bullet  to  solve  those  problems,  but  it  has  important  features  which 

has  more  meaning  in  skillful  hands.  Following  sections  evaluates  various  criteria  to  put 

forward  the  compared  performances  of  0-0  against  nonO-0  programming  environments. 

B.  COMPARISON  CRITERIAS 

1.     Modifiability 

No  software  is  perfect.  There  could  be  always  errors.  Even  though  a  software 
meets  requirements  of  the  user,  later  the  user  will  probably  demand  something  more  from 
that  software.  Modification  is  needed  for  two  reasons: 

•  Errors 

•  New  requirements  on  the  software 

Modification  is  almost  similar  to  fixing  or  modifying  a  car.  If  the  system  is 
complex,  modification  should  be  located  on  the  design  job  first.  The  role  of  design  job  or 
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architecture  of  the  system  is  to  avoid  getting  lost  in  the  complexity  of  the  system.  So  the 
design  should  be  consistent  with  the  system.  There  are  two  step  for  modification: 

•  Locating  the  modification  point(s)  in  the  software  system 

•  Performing  the  modification 

First  step  is  mostly  effected  from  the  design  tools,  while  the  second  one  from 
programming  language  environment.  The  keywords  for  both  steps  are  clarity  and 
consistency. 

Windows  programming  environment  provides  some  modification  easiness  of  its 
own:  Control  tools  (like  buttons,  string  table,  accelerations  etc.)  which  can  be  observed 
from  Borland  C++  Resource  Workshop,  can  be  modified  without  even  recompiling  the 
whole  software. 

The  relationship  between  major  0-0  features  and  modification  will  be  discussed 
on  next  section. 

a.  Encapsulation 

Modification  may  come  with  some  extra  problems  like: 

•  Increasing  the  complexity  of  the  system  unnecessarily 

•  Endangering  integrity  of  data  in  the  modules  of  the  software 

In  C++,  providing  encapsulation,  every  object  is  responsible  of  its  data  and 
detail  of  its  implementation.  Mostly,  objects  hides  their  data  from  outer  world,  they  just 
allow  outer  objects  to  use  service  or  member  functions  to  reach  specific  data  of  their  own. 

b.  Inheritance 

Multiple  inheritance  is  still  in  dispute  about  whether  it  is  a  strength  or  move 
of  a  "white  elephant",  in  O-O  world.  C++  supports  multiple  inheritance  and  should  be  used 
carefully,  since  it  could  be  a  big  problem  for  modification.  All  the  inheritance  concept 
mentioned  in  this  research  is  single  inheritance. 
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Suppose  that  FireCommandsWndcis  is  a  class  and  has  member  functions  of 
f  l  ( ) ,  f  2  ( ) ,  f  3  ( ) ,  and  so  on.  After  a  time  it  become  necessary  to  make  some  modifications: 
changing  the  implementation  of  f  l  ( ) ,  adding  a  new  behavior  of  f  new  ( ) . 

In  the  conventional  paradigms,  modules,  which  does  not  reflects  the  user 
requirements,  should  be  either: 

•  Thrown  away,  since  they  are  not  functional  any  more:  If  a  replacement  is  required,  a 
new  module  should  be  created  from  scratch.  Old  code  is  wasted  and  becomes 
completely  unfunctional. 

•  Modified:  Software  integrity  should  be  preserved.  Modified  part  of  the  code  is  lost. 

For  the  0-0  paradigm,  inheritance  is  another  chance  for  reusing  of  the  old 
code:  Creating  another  class  which  inherits  from  FireCommandWndcis,  overloading  f  l  ( ) 
and  having  fnew( )  member  function.  Big  portion  of  the  old  code  is  still  functional  and  the 
rest  can  still  be  used  by  others.  Since  the  old  code  is  preserved,  its  reliability  is  preserved 
too. 

c.    Polymorphism  (dynamic  binding) 

Consider  the  following  sample  codes  derived  from  the  OChart  application: 
A  base  class: 

class  SelectionToolCls 
{ 

public : 


}; 


virtual  void  DoMouseDown ( long,  long); 
virtual  void  DoMouseMove ( long,  long); 


Child  classy 


class  DistanceToolCls  :  public  SelectionToolCls 

{ 

public : 

virtual  void  DoMouseDown ( long,  long); 
virtual  void  DoMouseMove ( long,  long); 
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}; 


Child  class,: 


class  NewToolCls  :  public  SelectionToolCls 
{ 

public : 

virtual  void  DoMou se Down ( long,  long); 
virtual  void  DoMouseMove ( long,  long) ; 

>; 

DistanceToolcis  and  NewToolCls  are  two  sample  classes  with  their  base 

class  of  SelectionToolCls.  They  all  represent  a  button  on  the  screen.  If  a  user  selects  one 

of  them  then  an  appropriate  action  should  take  place.  Those  actions  are  the  same  by  title 

but  different  by  implementations.  Since  the  interaction  of  the  user  can  not  be  estimated  in 

advance,  conventional  methodologies  search  for  the  user's  interaction  by  case-like 

statements/functions.  Each  time  the  user's  decision  is  wondered  then  it  is  searched.  Adding 

and  deleting  buttons  make  the  user  to  update  all  the  case  groups. 

Dynamic  linking  or  polymorphism  makes  modification  easier  and  more 
reliable  than  conventional  paradigms.  Declaring  a  host  pointer: 

SelectionToolCls  *Selection; 
DistanceToolcis    DistanceTool ; 
NewToo 1 C 1 s         NewToo 1 ; 

And  assigning  sub-object  to  the  pointer  when  needed: 

Selection  =  ^Distance; 

or 

Selection  =  NewToo 1 ; 

Above  assignment  are  made  after  user's  interaction.  Within  the  code: 

Selection->DoMouseMove ( . . ) ; 

or 

Select ion->DoMouseDown ( . . ) ; 
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The  pointer  selection  is  independent  from  address  object.  It  will  be 
bounded  dynamically  and  will  retrieve  appropriate  class's  virtual  member  function  (which 
is  last  assigned  one  to  the  pointer).  When  a  modification  is  needed,  creating  a  new  child 
class  and  making  an  assignment  under  a  button  control  is  sufficient.  Polymorphism  makes 
the  code  shorter  and  clear,  so  helps  the  modification. 

2.  Efficiency 

The  goal  of  efficiency  implies  that  a  software  system  should  operate  using  the  set 
of  available  resources  in  an  optimal  manner  [Ref.3:  p. 301.  Resources  are  grouped  into  two: 

•  Time  resources 

•  Space  resources 

The  use  of  resources  is  mostly  dependent  on  hardware  and  the  algorithm  which  is 
used  in  the  software.  The  0-0  programming  paradigm  does  not  have  significant  impact  on 
efficiency. 

3.  Reliability 

The  software  system  should  operate  for  long  periods  of  time  without  human 
intervention.  This  gains  more  importance  especially  for  mission-critical  applications. 
Software  engineers  accept  that  there  is  no  perfect  software.  The  goal  to  minimize  the 
failures  which  endanger  the  mission.  For  increasing  reliability,  OOPLs  provide: 

•  Object  structure:  Provides  realistic  mapping  from  real-world  objects  to  form  the 
problem  domain. 

•  Encapsulation:  Protects  the  objects'  own  privacy  and  provide  data  integrity. 

•  Reuse  of  reliable  objects:  Assuming  the  old  objects  are  well-tested,  reusing  of  them  via 
inheritance  eases  the  testing  of  the  new  object(s). 

4.  Understandability 

Understandability  is  essential  for  modification  and  project  management,  because 
of  the  need  for  coordination.  Understandability  is  dependent  upon  programming  language 
and  tools.  Language  is  the  way  to  express  the  real- world  solution  [Ref.3:  p.31]. 


40 


One  of  the  fundamental  differences,  which  distinguishes  0-0  from  nonO-0  is 
mapping  from  problem  domain  to  software  solutions.  Conventional  methodologies 
decompose  a  system  into  modules  for  which  each  module  represent  a  major  step  in  overall 
process.  Object-oriented  methodology  keeps  the  real-world  objects  or  decompositions  in 
their  abstraction  and  represent  them  in  objects.  "Call  for  Fire"  process  which  is  send  from 
an  observer  to  FDC  for  being  a  fire  request,  can  be  represented  as  an  object  in  0-0.  It  has 
verbal  operations  and  noun  phrases,  which  describe  its  behaviors  just  like  the  real-world 
objects.  It  keeps  its  unity  and  communicates  with  other  objects.  The  benefits  of  objects: 

•  Similarity  of  objects  to  the  real-world  objects  makes  disowning  of  O-O  projects  easier 
and  more  readable. 

•  Dealing  with  object  modules  is  similar  to  real-world  objects,  so,  maintains, 
modification  and  extensibility  of  the  software  is  easier  then  conventional  ones  which 
are  created  by  using  top-down  structured  design. 

•  For  large  projects,  it  is  easier  to  decompose  the  job  without  losing  semantics  of  sub 
modules.  This  increases  the  reliability  of  subparts. 

5.     Code  Size  and  Cost 

One  of  the  tools  to  estimate  the  cost  of  a  software  is  Cocomo  .  Cocomo  is  a  lines- 
of-code-based  costing  model  that  estimates  the  software  development  cost.  The  cost  is 
determined  with  the  formula: 

SM  =  A  *  KSLOCB 

In  the  equation,  SM  is  the  number  of  staff-months  which  is  required  to  complete 
the  system  development;  A  is  an  empirically  derived  number  that  converts  1000  lines  of 
code  into  its  equivalent  cost  in  SM;  KSLOC  is  the  lines  of  source  code  (expressed  in 
thousands);  and  B  is  a  factor  that  compensates  for  the  nonlinear  nature  of  software 
development.  [Ref.19:  p. 363] 

The  role  of  0-0  in  decreasing  the  Line  of  Code  (LOC)  shows  itself  with  its  reuse 
capability.  Reusing  becomes  more  effective  when: 


1.  Barry  Boehm's  Constructive  Cost  Model  to  estimate  effort,  man  power,  and  so  on  [Ref.2]. 
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•  The  size  of  code  (or  project)  is  too  large  (in  ten  thousands  of  LOC) 

•  Application  completely  or  partially  use  high  degree  of  reusable  software  components, 
like  GUI  component. 

One  point  should  not  be  disregarded,  reuse,  like  cache  memories,  provides 

diverse  performances  on  different  problem  domains  and  it  mainly  depends  on  design. 

6.     Portability 

Portability  is  mostly  dependent  on  both  language  and  environment.   0-0 
paradigm  contributes  to  portability  with  its  encapsulation  feature. 

FIGURE  10  on  page  42    displays  a  sample  Borland  C++  include  file  which 


#ifdef  BORLANDC 

//     PC-specific  includes 
#      include  . . 

#endif 


#ifdef  Unix 

//     UNIX-specific  includes 

#     include  . . 


#endif 


Figure  10:  Selective  includes  of  a  sample  Borland  C++  header  file. 

behaves  selectively  for  include  files.  Compiler  checks  the  operating  system  and  uses  the 
appropriate  include  files.  Since  all  the  modules  and  objects  have  two  parts  which  are 
interface  and  implementation,  implementation  part  could  have  specific  features  to  its 
environment.  The  User  or  programmer  is  not  interested  in  that  part.  To  port  a  software  to 
another  environment  requires  compiling  &  linking  again. 

7.     Project  Management 

Designing  and  implementing  systems  consisting  of  tens  of  thousands,  if  not  millions, 
of  lines  of  code  is  quite  different  matter.  The  effort  required  to  complete  such  a  system 
is  clearly  beyond  the  intellectual  physical  capacity  of  one  person.  [Ref.3:  p. 7] 
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Gathering  more  people  into  a  single  project  creates  other  problems: 
Communication  and  coordination. 

FIGURE  1 1  on  page  43  displays  the  resource  allocation  for  0-0  FATDS  /  FS  in 
terms  of  time.  The  time  which  is  spent  for  analysis  and  design  is  more  than  coding.  This 
one  of  the  characteristics  of  O-O.  Design  decisions  effect  the  future  works.  Reuse  should 
be  a  project  goal  like  any  other  [Ref.16:  p. 44]. 


Resource^, 

■ 

Analysis 

Design       Coding      Testing 

Figure  11:  Time  allocation  for  development  elements. 


a.    Project  Organization 

There  are  four  types  of  alternative  project  development  styles  [Ref.16:  p.44]: 

•  Rapid  prototyping 

•  Round-trip 

•  The  iterative  style:  Develops  a  series  of  solutions  to  a  problem,  each  one  close  to 
satisfying  the  requirements.  Each  solutions  is  complete  but  its  accuracy  or 
acceptability  improves  with  each  pass. 

•  The  incremental  style:  Builds  system  functionality  a  little  at  a  time.  It  differs  from 
iterative  development  in  that  the  results  of  each  increment  are  not  an  entire  solution, 
but  part  of  it.  This  style  has  been  advocated  for  some  time  for  conventional  projects. 
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Object-oriented  development  is  best  suited  to  the  iterative  or  incremental 
style  of  development.  Abstraction  of  the  real  world  objects  in  0-0  terms  makes  possible  to 
work  with  objects  or  modules  independently.  Object  can  be  put  in  action  as  soon  as  it 
possible  whether  they  are  completely  ready,  or  not.  This  gives  a  chance  for: 

•  Early  evaluation  of  objects  which  justifies  the  rest  of  the  work. 

•  Estimating  the  cost  of  the  remaining  job  more  realistically. 

•  Allocating  the  resources  equally  for  mid-term  goals. 

For  is  research  a  model  named  model-based  project  development  cycle,  has 
been  applied  for  FATDS/FS.  It  is  both  incremental  and  iterative.  FIGURE  12  on  page  44 
shows  the  object  development  algorithm  with  MBPDC.  OOD  sets  the  goals  of  each  object. 
Since  an  object  may  not  be  fully  functional  at  moment  during  the  implementation-testing 
process,  mid-term  expectations  should  be  planned  for  them  (current  goal(s)). 


Create  new  object 


Put  the  object  in  the  big  picture 


modify  it  or 
increment/iterate  its 
implementation 


N 


Y 


Figure  12:  Object  development  in  MBPDC. 


44 


Conventional  design  methodologies  have  the  problem  of  decomposing  the 
problem  domain  in  to  functional  sub  units.  Since  their  modules  represent  verbal  actions, 
conventional  languages  are  not  good  for  iterative  development  cycle. 
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V.  DATABASE  MANAGEMENT  SYSTEM  (DBMS)  SELECTION  FOR  FATDS 

A.  INTRODUCTION 

FATDS  has  a  great  deal  of  data  to  manipulate.  Data  should  be: 

•  Kept  in  reliable  environment(s) 

•  Shared  from  other  nodes  of  the  system 

FATDS 's  database  system  should  provide: 

•  A  distributed  environment:  Supporting  multiple  workstations  connected  to  a  local  or 
wide-area  network,  with  one  or  more  database  servers  providing  transparent  access  to 
multiple  data  sources. 

•  An  advanced  user  interface:  Provided  by  a  graphics  workstation  or  PC  with  the 
capability  of  integrating  text,  graphics,  pictures,  and  possibly  sound  and  video. 

Before  implementing  the  database  part  of  the  project  two  questions  should  be 
answered;  First,  what  will  be  the  DBMS' s  source?  It  could  be: 

•  Programming  language's  own  DBMS. 

•  Application  Developers's  own  DBMS. 

•  Commercially  available  DBMS. 

Second,  what  will  be  the  database  model  for  DBMS?  It  could  be: 

•  Object-oriented  database  model. 

•  Other  database  models. 

•  Composition  of  database  models. 

B.  CHOOSING  A  DBMS  SOURCE 

1.     Programming  language's  own  DBMS 

Borland  C++  does  not  have  a  built-in  DBMS  like  most  of  the  other  programming 
languages.  If  the  programming  language  has  provided  a  DBMS,  then: 

•  It  would  be  completely  object-oriented. 

•  It  may  be  easy  to  embed  DBMS  functions  or  objects  into  the  source  code. 

•  It  may  not  be  satisfactory  for  the  applications  requirements,  e.g.,  security,  integrity, 
suitability  to  distributed  databases  and/or  for  large  objects. 
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•  There  would  still  be  problems  about  using  existing  databases  (which  have  been  created 
by  other  DBMSs. 

♦  It  would  have  enforce  to  use  the  same  language's  native  DBMS  format  for  other 
applications. 

2.  Application  Developers's  own  DBMS 

Another  option  is  to  develop  a  DBMS  which  has  been  created  specially  for  the 
project  or  general  purpose.  It  is  not  commercially  available.  If  it  is  task-oriented  then  it 
meet  all  the  requirements  of  the  project  and  acts  well  with  the  application  code.  It  does  not 
have  to  be  implemented  with  application's  language,  but  to  embed  database  system  calls 
there  should  be  third  party  communication  programs  in  application's  language. 

One  of  the  features  of  this  implementation  is  that  it  is  completely  object-oriented 
like  the  first  option.  Since  this  choice  under  the  control  of  the  application  developer,  it  can 
be  maintained  or  modified  according  to  requirements. 

The  problem  with  these  kind  of  DBMSs  is  maintenance.  Its  development  should 
be  included  into  the  project,  hence,  this  increases  the  project  burden. 

3.  Commercially  available  DBMS 

Commercially  available  DBMSs  are  also  for  general  purpose,  however  there  is  a 
selection  option  according  to  the  project  requirements.  These  DBMSs  are  developed 
outside  the  project  (FATDS)  environment,  so,  developing  a  DBMS  never  be  another  task, 
but  to  use  it.  It  is  possible  to  use/create  various  databases  other  than  the  project's.  If  it  is  a 
widely  used  commercial  DBMS,  it  will  possibly  be  used  longer. 

Disadvantage  with  this  choice  is  maintance.  Only  the  DBMS  vendor  can  provide 
necessary  modifications  on  the  application. 
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4.     Choosing  the  DBMS  Source  for  FATDS 

Using  a  commercially  available  DBMS  is  chosen  for  FATDS.  If  it  does  not 
specifically  violates  the  requirements,  "buying  a  product  is  generally  cheaper  then 
producing  it". 

One  of  the  advantages  of  commercial  DBMSs  is  that  database  can  be  created 
without  using  the  host  application.  This  provides  to  use  the  same  database  from  other  type 
of  applications  locally  or  via  network. 

C.     CHOOSING  A  DATABASE  MODEL 

1.     Database  Model  Options 

There  are  various  data  models.  The  major  data  models  are  hierarchical,  network, 
relational  and  object  data  models.  Each  of  the  data  model  is  not  alternative  of  the  other(s). 
There  are  advantages,  disadvantages  and  suitable  applications  for  each  the  data  models. 

In  hierarchical  data  model,  data  is  organized  in  inverted  tree  structure  and  is 
accessed  form  the  top  the  bottom  in  a  series  of  nodes  similar  to  branches  in  a  tree.  The 
inverted  tree  structure  provides  clearly  defined  and  fixed  path  for  accessing  the  data  by 
traversing  the  branches  of  the  tree.  The  rigidity  of  the  structure  has  some  disadvantages  in 
that  new  access  path,  not  defined  at  he  outset,  may  complicated  or  even  impossible  to 
achieve.  Modification  of  the  database  structure  is  a  very  complex  task. 

The  network  data  model  traded  off  some  of  the  high-access  performance  for 
flexibility  in  organizing  and  accessing  the  data.  As  in  a  hierarchical  model,  the  data  is 
organized  in  and  inverted  tree.  The  greater  flexibility  is  achieved  by  allowing  a  node  to  be 
connected  to  more  than  one  branch.  Records  are  linked  by  predefined  pointers.  Equal  or 
better  performance,  as  compared  to  the  hierarchial  model,  was  achieved  by  maintaining 
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permanent  pointers  linking  records.  The  complexity  of  the  data  structure  made  queries 
more  complex  and  modification  and  ad  hoc  queries  more  complicated 

The  relational  data  model  promised  a  structure  that  met  these  new  requirements. 
Structurally  different  from  inverted  trees  of  the  hierarchical  and  network  data  models,  data 
in  the  relational  data  model  is  stored  in  tables  consisting  of  columns  and  rows.  Links 
between  data  records  are  largely  established  as  needed  on  an  ad  hoc  basis.  The  rows  of  a 
table  represent  records  and  the  columns  within  a  table  represent  the  fields  in  a  record. 
Different  types  of  records  are  stored  in  separate  tables.  Some  frequently  used  connections 
between  tables  can  predefined,  while  others  can  be  established  at  the  time  of  query.  The 
data  and  their  description  are  maintained  separately,  but  changing  data  description  is  not 
simple.  This  model  achieved  the  desired  flexibility  and  ease  of  use,  but  at  a  cost.  The 
relational  data  model  requires  a  higher  level  of  processing  to  establish  connections  and 
access  data.  Consequently,  system  requirements  for  processor  and  memory  are  higher  to 
achieve  the  same  level  of  overall  performance. 

The  Object  data  model  differs  itself  from  other  models  representing  real-world 
data  in  intelligent  objects  which  combines  the  abstraction  and  behavior  of  the  real-world 
objects.  Direct  correspondence  between  real-world  and  database  objects  maintains 
integrity  and  identity  of  objects  so  they  can  be  easily  identified  and  operated  upon  [Ref.  13: 
p.442].  Objects  have  their  own  behaviors,  this  provides  them  to  interact  with  other  data 
models.  Advantages  of  the  object  data  model:  [Ref.  13:  p. 444] 

•  Extensibility:  Object  types  and  their  methods  can  be  modified  as  needed.  Such  changes 
are  localized  to  the  relevant  object  type  and  hence  are  much  easier  than  in  record- 
based  system. 

•  Behavioral  constraints:  Because  of  encapsulation,  the  behavior  of  each  object  type  is 
predetermined  by  a  fixed  set  of  methods.  Hence,  database  operations  are  constrained 
to  be  within  these  behavioral  specifications. 

•  Flexibility  of  type  definition:  The  user  is  not  limited  to  the  modeling  concepts  of  data 
model  but  can  define  many  variations  of  data  types,  each  with  unique  properties. 
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•  Modeling  power:  The  inheritance  of  both  attributes  and  methods  is  very  powerful  tool 
for  data  modeling.  In  general,  the  abstractions  of  generalizations! specialization, 
identification,  and  aggregation  are  well  supported  in  the  current  data  models. 

Disadvantages  of  the  object  data  model: 

•  Lack  of  associations:  The  abstraction  of  association  is  not  directly  supported  and  is 
achieved  indirectly  by  allowing  inter  object  references.  This  is  an  inherent  weakness  of 
the  0-0  approach. 

•  Behavioral  rigidity:  The  predetermining  and  prespecifying  all  operations  by  a  fixed  set 
of  method  create  this  rigidity. 

•  No  high-level  query  language:  There  are  no  high-level  query  languages  for  current 
data  models. 

2.  Interfacing  Objects  with  the  Other  Models 

Object-oriented  databases  provides  to  write  and  read  objects  to  the  disk,  normally 
using  static  or  dynamic  link  libraries  with  the  code.The  physical  storage  format  on  the  disk 
is  hidden  from  the  application.  The  format  can  be  flat  files,  relational  files,  hierarchical 
files,  or  any  other  type. 

The  most  primitive  OODBMSs  use  a  custom  file  format  and  enable  you  to  only  store 
objects  on  disk.  These  products  offer  little  advantage....  Likewise,  the  manufacturers 
of  these  products  require  you  to  purchase  their  software  and,  occasionally,  a  run-time 
license  for  each  product  distributed.  [Ref.20:  p.5] 

A  OODBM  may  either: 

•  Store  its  objects  using  a  format  compatible  with  existing  commercial  database 
management  systems  such  as  Oracle,  Sybase,  dBase  IV,  or  Paradox:  Data  consistency 
is  ensured  and  all  transactions  are  performed  internally  by  the  OODB.  The 
disadvantages  are  technical  difficulties  and  the  relatively  slow  performance. 

•  Exists  in  parallel  with  a  commercial  database  management  system  that  mirrors  the  data 
in  the  object-oriented  database:  It  requires  an  update  scheme  to  ensure  that  the  data  in 
both  databases  remains  in  synch.  Accessing  data  in  an  object-oriented  database  is 
much  faster  -2  to  10  times  faster-  than  in  an  relational  database. 

3.  Choosing  a  Data  Model  for  FATDS 

There  is  no  single  data  model  which  completely  fits  FATDS 's  database 
requirements.  Object-oriented  databases  can  interface  with  other  data  model.  This  provides 
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the  opportunity  of  combining  the  advantages  of  different  data  models.  For  this  research, 
interfacing  objects  with  relational  DBMS  is  selected. 

In  relational  DBMSs,  the  structured  organization  of  data  in  tables  and  the 
capability  of  the  database  system  to  interpret  each  column  of  data  serves  well  for 
applications  involving  pure  numerical  and  textual  data.  Variable  length  data  elements  such 
as  free-form  text,  images,  and  voice  does  not  fit  into  the  structure  of  relational  databases. 
Relational  database  vendors  created  a  new  class  of  data  type  called  Binary  Large  Objects 
(BLOBs).  These  data  types  can  hold  very  large  (and  variable  length)  data  and  they  are  not 
interpreted  by  the  database.  This  new  feature  provides  relational  DBMSs  to  support 
multimedia  data  management. 

Relational  database  model  has  advantages  that  the  OODBM  can  not  support: 
[Ref.22:  p.68][Ref.26:  p.33] 

•  The  relational  schema  is  stored  in  the  database  catalog. 

•  General-purpose  query  programs  can  use  the  catalog. 

•  The  SELECT,  PROJECT,  and  JOIN  operators  can  build  new  database  views  at  run 
time. 

•  The  database  is  cross-compatible  with  other  applications  that  use  the  same  DBMS. 

•  The  data  and  their  description  are  maintained  separately. 

The  object  data  model  has  advantages  that  the  relational  data  model  can  not 
support  [Ref.22:  p.68][Ref.l8:  p.  169]: 

•  Variable  length  data  member:  It  can  support  such  applications  as  imaginary, 
multimedia,  geographic  data,  weather. 

•  Abstraction:  The  behavior  of  an  object  is  described  by  a  class  definition  that  is  created 
by  data  abstraction.  By  incorporating  data  abstractions  at  the  level  of  the  database,  it 
is  possible  to  make  changes  to  the  way  a  database  class  is  implemented. 

•  Class  extensibility:  In  a  relational  database,  the  only  parameterizable  type  is  a 
relation,  and  the  only  operations  possible  on  all  relations  are  get_field_value  and 
set_Jield_value.  In  the  object  data  model,  interface  of  each  object  is  customized  to  that 
object. 

•  Arrays  permit  repeating  groups. 
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•  Encapsulation:  Encapsulation  of  data  formats  with  methods  bind  data  representation 
and  behavior. 

•  Polymorphism:  Customizes  the  behavior  of  derived  data  types. 

•  Integrity:  Especially  for  large  systems,  the  integrity  of  analysis,  design  and 
programming  to  map  the  real-world  data  into  objects  provides  the  simplicity  to  build 
the  database  system.  This  provides  easy  maintenance  of  the  database  system. 

•  Reusability  and  adaptability:  They  are  the  two  important  features  of  object-oriented 
systems,  which  are  accomplished  using  inheritance. 

•  OODBMSs  are  faster:  Because,  relational  databases  pull  information  from  a  variety  of 
tables  into  one  result  set,  based  on  JOIN  operation  while  OODBMSs  make  the  same  job 
by  calling  member  functions. 

•  Automatic  type  checking  at  the  point  of  use:  The  object-oriented  database  performs 
type  checking  on  the  arguments  to  method  calls.  Thus,  type  errors  are  detected  at  the 
time  of  invocation  rather  than  at  the  end  of  a  transaction. 

•  Schema  evolution:  Conventional  data  models  do  not  support  efficient  mechanisms  for 
schema  evoluton.  Object  data  model  allows  user-defined  operations  making  the 
addition  easier.  Schema  evolution  includes  changes  to  the  defination  inside  a  class  and 
changes  to  the  structure  of  the  class  lattice.  A  set  of  invariants  and  rules  can  be  defined 
so  that  the  schema  will  remain  consistent  as  it  evolves. 

D.     DBMS  FOR  FATDS 

FATDS's  database  is  implemented  in  object-oriented  fashion  which  interfaces  a 
commercial  DBMS,  Paradox.  Borland's  Paradox  for  Windows,  version  1.0,  is  a  relational 
DBMS.  Paradox  provides  network  support,  password  protection  using  encryption,  binary 
large  objects  (BLOBs),  multiple  indexes,  and  composite  indexes. 

To  use  Paradox  table  in  the  applications  and  embed  into  the  C++  source  code  a  third 
party  Engine  is  need:  Paradox  Engine.  The  Paradox  Engine,  version  3.0,  is  and  API 
containing  more  than  90  functions  accessible  from  a  C,  C++,  or  Pascal  program.  The 
Engine  provides  to  create  database  tables  and  indexes  and  to  perform  all  database-related 
operations.  The  Paradox  Engine  is  implemented  as  a  DLL  (for  windows)  that  can  be 
distributed  royalty-free.  The  problem  with  the  Engine  is  the  DLL  file  is  implemented  in  C, 
so  it  is  not  object-oriented.  To  keep  the  applications  completely  implemented  in  O-O, 
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another  DLL  file  is  created,  which  is  in  O-O.  The  design  and  implementation  issues  of 
FATDS's  database  is  discussed  in  the  next  chapter. 

The  benefits  or  advantages  of  this  choice: 

•  Working  with  other  data  format  files  too:  The  applications )  may  have  to  work  with 
other  data  formats.  FIGURE  13  on  page  53     displays  the  object-interfaced  data 


Application! 


X  database 


Paradox 
database 


Any  DBMS,  other  then  Paradox 


Paradox  for  Windows 


Figure  13:  Object-interfaced  data  environment 


environment.  Objects  can  be  implemented  to  filter  diverse  database  formats,  hiding 
unnecessary  details  from  the  users  and  end-programmers.  On'y  the  database  object  are 
necessary  to  be  updated  according  to  the  target  database,  not  the  application.  This 
makes  the  modification  easier. 

Using  a  reliable  DBMS:  Instead  of  creating  a  DBMS  which  is  normally  a  independent 
task,  using  a  commercially  developed  (so  testedO  provides  more  reliable  DBMS 
environment. 

Faster  database  development:  Data  does  not  have  be  created  or  maintained  by  the 
mission-oriented  applications.  It  should  be  created! maintained  without  running  the 
application  or  creating  a  special  program.  Database  design  and  implementation  of 
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FATDS,  including  custom  forms,  can  be  created  by  Paradox  for  Windows,  without 
using  any  user-created  application. 

Using  the  data  with  other  applications:  Other  applications  created  independent  from 
FATDS  may  use  the  same  data.  Regarding  the  hugeness  of  the  project  and  time  period 
of  using  the  application,  generally  accepted  data  formats  provides  flexibility  in  use. 
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VI.  OBJECT-ORIENTED  DATABASE  DESIGN  OF  FATDS 

A.     INTRODUCTION 

The  database  system  of  FATDS  is  determined  as  object-oriented  database  system 
which  incorporates  a  relational  DBMS.  OODBMS  has  a  front-end  role  in  this  system  and 
back-end  could  be  any  DBMS  in  any  data  model.  Object  structure  of  the  system  facilitates 
to  work  with  heterogenous  back-ends.  Using  various  DBMSs  as  a  back-end  effects  the 
design  of  the  database.  Back-end  database  could  be: 

•  Created  independent  from  the  front-end  implementation. 

•  Created  simultaneously  or  incorporating  with  the  front-end. 

Two  of  the  situations  may  effect  the  object  design  differently.  Creating  the  object- 
database  as  a  front-end  together  with  the  back-end  database  may  increase  the  reusability  of 
the  objects  for  later  developments.  For  this  research  first  option  is  followed  to  show: 

•  How  object-oriented  database  systems  coexists  with  the  existing  databases. 

•  The  benefits  of  object-oriented  database  system  interfacing  with  relational  DBMSs. 

One  of  the  benefits  of  the  of  OODBMSs  is  their  implementation  language.  Non-O-0 
database  system  mostly  have  their  own  data  languages  which  are  not  capable  of  complete 
computational  power  like  programming  languages.  OODBMSs'  languages  are  complete 
programming  languages  as  well.  This  facilitates  to  combine  database  development  and 
program  development  together. 

Design  methodology  will  follow  the  steps: 

•  Identify  the  basis  for  the  database  requirements 

•  Define  the  database's  functional  and  performance  requirements 

•  Conceptual  design 

•  Identify  classes 

•  Identify  attributes  and  services  (member  functions) 

•  Identify  the  relationship  between  classes 

•  Database  implementation 
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B.  DATABASE  REQUIREMENTS  AND  ANALYSIS  OF  FATDS 

1.     The  Role  of  Artillery 

The  mission  of  field  artillery  (FA)  is  to  destroy,  neutralize,  or  suppress  the  enemy 
by  cannon,  rocket  and  missile  fires  and  to  assist  in  integrating  fire  support  into  combined 
arms  operations.  The  main  role  of  FA  is  to  ease  the  achievement  of  commander's  objective 
with  its  fire  power.  The  commander  is  a  maneuver  unit  commander  at  any  level. 

Targets  could  be  anything  on  the  battlefield:  Enemy  units,  bridges,  areas,  roads, 
tanks,  trenches,  convoys,  etc.  Main  point  is  that  targets  are  not  artillery's,  but  the 
commander's.  So,  all  the  target  acquisition  elements  work  under  the  maneuver 
commanders'  control. 

Since  artillery  normally  does  not  have  eye  contact  with  the  enemy  targets,  he 
relies  on  different  sources  for  the  target  information;  forward  observers,  air  observers, 
radars,  electronic  counter  measure  units,  higher  headquarters,  reconnaissance/intelligence 
units,  commander  himself,  etc.,  almost  everybody  on  the  battlefield  is  source  for  target 
acquisition.  A  target  could  be  immediate  one  or  planned  before. 

Depending  on  the  organization  of  the  FA  there  could  be  diverse  weapons  systems. 
Each  weapon  system  has  its  own  munitions  and  firing  tablesr  Firing  table  is  a  book  which 
displays  all  numeric  data  about  a  specific  gun  &  munition(s)  combination. 

Although  there  are  many,  only  the  following  major  application  functions  are 
taken  into  account  for  database  implementation: 

•  Target  management 

•  Gun  management 

•  Firing  table  management  (Table-F  only) 

Other  database  areas  are: 
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•  Corrections  management:  //  keeps  and  manipulates  firing  corrections  for  each  gun  and 
position  pairs. 

•  Fired  mission  history  management:  It  is  a  derived  database  management. 

•  Known  points  management:  Radars,  observation  post  positions,  etc.,  are  all  known 
points. 

•  Ammunition  management:  Amounts,  type,  caliber,  lot  are  the  fields  to  be  managed.  (It 
is  designed  but  not  implemented.) 

•  Met  messages  management:  It  keeps  up-to-date  met  messages. 

•  Friendly  forces  management:  Positions  of  friendly  forces  and  other  regions  which  are 
necessary  for  fire  coordination,  planning  and  security. 

2.     Application  Functional  Requirements  Overview 

a.    Target  Management 

Each  target  is  assigned  a  number  like  "AB2124".  First  three  digits  represent 
a  specific  unit  or  element  while  the  rest  represent  consecutively  target  numbers  which  are 
assigned  to  that  unit/element.  All  the  targets  should  be  located  at  least  with  its  coordinates, 
height  and  description.  In  addition  to  those:  source  (who  located),  locating  accuracy, 
located  time,  category  (there  are  13  category  groups  and  each  target  fits  at  least  one  of 
them),  fired/notFired,  priority,  restrictions. 

Targets  could  be  a  point,  a  region  (with  a  size),  target  groups  (two  or  more 
targets  with  a  different  identification  name),  target  series  (more  than  one  targets  and/or 
target  groups  with  a  special  name).  Battalion  FDC  can  form  a  target  groups  and  series.  A 
sample  group  name  is  B 1C;  letters  represents  who  forms  that  group,  the  number  digit  in  the 
middle  is  consecutive  group  number.  A  sample  name  for  series  of  targets  is  CASEY,  just  a 
nick  name. 

The  decisions  that  comrise  the  decide  function  include: 

•  What  targets  should  be  acquired  and  attacked. 

•  Where  and  when  the  targets  will  likely  be  found  and  who  can  locate  them. 

•  How  the  targets  should  be  attacked. 

•  Whether  target  damage  assesment  is  required. 

FDCs  will  be  able  to  keep  track  of  unlimited  number  of  targets. 
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b.  Gun  management 

Each  gun  has  a  unique  number  within  a  battery.  Together  with  battalion  name 
and  battery  name  each  gun  has  a  unique  name.  Guns  can  be  organized  in  some  batteries  as 
platoons  (four  guns  in  a  platoon  and  two  platoon  in  a  battery),  if  not,  a  battery  has  six  guns. 
All  the  guns  in  battery  are  identical  to  each  other.  One  of  the  guns  in  the  battery  is  assigned 
as  the  main  gun. 

In  addition  to  name  and  each  gun  has  position  coordinates,  model,  maximum 
range,  maximum  left/right  deflection,  common  orientation  deflection,  orientation 
deflection,  firing  table  name. 

c.  Firing  Table  Management 

Each  gun  has  its  own  firing  table.  A  firing  table  is  composed  of  various  tables: 

Table- A:  Line  numbers  of  meteorological  message. 

Table-B:  Complementary  rang  line  number. 

Table-C:  Wind  components. 

Table-D:  Temperature  and  density  corrections. 

Table-E:  Propellant  temperature. 

Table-F:  Basic  data  and  correction  factors. 

Table-G:  Supplementary  data. 

Table-H:  Rotation-range. 

Table-I:  Rotation-azimuth. 

Table- J:  Fuze  correction  factors. 

Above  tables  are  for  specific   shell  type/model,   fuze  type/model   and 

propelling  charge/type. 

All  the  firing  table  data  are  constant.  Any  application  should  not  be  allowed 
to  modify  the  tables. 
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C.     DATABASE  DESIGN  OF  FATDS 

1.     Conceptual  Design 

FIGURE  14  on  page  60  and  FIGURE  15  on  page  61  display  the  ER  diagrams  for 
the  Target,  Gun  and  Table-F  entities.  The  conceptual  design  is  performed  according  to 
relational  data  model  concepts. 


2.     Identify  Classes,  Attributes  and  Services 

The  classes  which  are  formed  as  the  front-end  database  classes  are: 

•  DBGunCls:  Gun  database  management  class. 

•  DBTargetCls:  Target  database  management  class. 

•  DBTable_F_Cls:  Table-F  management  class. 


Tables  3,  4,  5  displays  the  data  members  and  data  functions  of  the  database 


classes: 


TABLE  3:  DATA  MEMBERS  WHICH  ARE  USED  BY  ALL  THE  DATABASE  CLASSES. 


Name 

Access 

Description 

nFields 

Private 

Holds  number  of  the  fields  in  the  database  table. 

Names 

Private 

Holds  the  names  of  the  all  the  table  field  names. 

Types 

Private 

Holds  the  type  codes  for  each  field  of  the  database 
table. 
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Figure  14:  ER  diagram  for  FATDS/FS  schema  (gun,  target,  munition) 
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Figure  15:  ER  diagram  for  FATDS/FS  schema  (Table  F) 
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TABLE  4:  MEMBER  FUNCTION  WHICH  ARE  USED  BY  ALL  OF  THE  DATABASE  CLASSES. 


Name 

Access 

Description 

RecordTobuf f er 

Protected 

Takes  the  tield  values  from  the  database  table  from 
where  the  pointer  is,  and  puts  it  to  the  buffer  fields. 

ReadFirst 

Public 

Moves  the  database  pointer  to  first  record  and 
reads  the  record  into  the  record  buffer. 

ReadLast 

Public 

Moves  the  database  pointer  to  last  record  and 
reads  the  record  into  the  record  buffer. 

ReadNext 

Public 

Moves  the  database  pointer  to  next  record  and 
reads  the  record  into  the  record  buffer. 

ReadPrev 

Public 

Moves  the  database  pointer  to  previous  record  and 
reads  the  record  into  the  record  buffer. 

isTableEmpty 

Public 

Checks  the  table  if  it  exist  or  empty  and  return 
TRUE  if  it  is  empty. 

isLast 

Public 

Checks  the  if  the  pointer  is  at  the  last  record  and 
returns  TRUE  if  it  is  the  last  record. 

Reset 

Public 

Empties  the  record  buffer  and  sets  all  the  attributes 
to  initial  states. 
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TABLE  5:  MEMBER  FUNCTION  WHICH  ARE  MOSTLY  USED  BY  SOME  OF  THE  DATABASE 

CLASSES. 


Name 

Access 

Description 

Buf f erToRecord 

Protected 

Takes  the  values  from  the  buffer  and  puts  them  to 
the  database  table  to  where  the  pointer  is. 

AddRecord 

Public 

Adds  the  record  buffer  to  the  database.  (The  record 
is  appended  if  the  database  does  not  have  a 
primary  key  that  requires  the  database  to  be  kept  in 
sorted  order.) 

UpdateRecord 

Public 

Copies  the  record  buffer  into  the  database  as  an 
update  of  the  current  record. 

DeleteRecord 

Public 

Deletes  the  current  record. 

SearchByKey 

Public 

Searches  the  key  field  for  a  given  field  value. 

Set* 

Public 

Set  the  a  field  value  into  the  buffer  area. 

Get* 

Public 

Retrieves  a  field  value  from  the  buffer  area. 

Any  other  specific 
member  function(s) 

3.     Database  Implementation 

a.    Paradox  Database  Tables  Organization 

Table  6  displays  the  valid  field  types  used  in  Paradox  tables. 
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TABLE  6:  PARADOX  FIELD  TYPES 


Type 

Storage  Size 
in  Bytes 

Description 

N 

8 

Floating  point  number  with  15  significant  digits  in  the 
range  of  10"i07to  10  308. 

s 

2 

Integer  in  the  range  of  -32,767  to  32,767. 

$ 

8 

Same  as  floating  point,  but  fixed  at  two  digits  of  the 
decimal. 

D 

4 

The  date. 

Annn 

1  to  255 

NULL-terminated  string  of  length  nnn,  where  nnn  is 
less  than  255. 

Mn 

n+10,  where  is 

in  the  range  of  0 

to  240 

Unformated  text  BLOB,  n  represents  BLOB-related 
header  information,  and  the  actual  data  is  stored  in  a 
separate  file  pointed  to  by  the  file  name  stored  in 
Paradox. 

Bn 

n+10,  where  is 

in  the  range  of  0 

to  240 

Same  as  the  preceding,  but  for  unformated  binary 
information. 

Fn 

n+10,  where  is 

in  the  range  of  0 

to  240 

Same  as  the  preceding,  but  for  formated  text. 

On 

n+10,  where  is 

in  the  range  of  0 

to  240 

Same  as  the  preceding,  nut  for  Windows  OLE  objects. 

Gn 

n+10,  where  is 

in  the  range  of  0 

to  240 

Same  as  the  preceding,  but  for  graphics  data. 

b.    Database  File  Organization 

The  Paradox  Engine  provides  the  pxengwin.dll  DLL  file  together  with 
pxengine.h  header  file.  Engine  is  implemented  with  C  language,  thus  it  is  not  object- 
oriented.  The  Engine  with  its  more  than  90  functions  provides  all  the  database  file 
manipulations  including: 

•  Create,  read,  and  write  Paradox  tables,  record,  and  fields  in  DOS,  Windows,  and 
network  environments. 
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•  Create,  read,  and  write  Paradox  BLOB  fields. 

•  Support  explicit  interactive  Paradox  and  Paradox  Applications  Language  (PAL) 
applications,  as  well  as  other  Paradox  Engine  Applications. 

•  Support  other  Paradox  features  such  as  password  protection,  encrypted  table,  date 
encoding,  searching,  and  error  handling. 

•  Import  data  into  Paradox  tables  through  serial  communications,  such  as  when 
downloading  form  mainframes  or  from  external  devices  that  can  not  be  reached  from 
PAL. 

•  Create  stand-alone  applications  or  applications  that  can  be  run  with  the  PAL  RUN 
command. 

FIGURE  16  on  page  66    displays  the  file  organization  for  the  database 

development  of  FATDS.  In  order  to  create  an  object-oriented  database  engine,  another 

DLL  file  is  created  namely  paradox.dll.  Paradox.dll  is  created  with  the  files: 

•  Paradox.*:  Loads  other  header  files  required  for  others,  support  proper  memory 
allocation  if  multiple  applications  are  simultaneously  using  the  paradox.dll. 

•  Pdoxeng.*:  Initialize  the  engine  and  shuts  it  down. 

•  Pdoxrec.*:  Performs  single  record  operations  in  a  database  table  such  as  putting  data 
into  the  field  or  get  data  from  the  field. 

•  Pdoxtab.*:  It  the  engine  is  initialized  it  attempts  to  open  a  specific  database  table.  If 
there  is  not  that  table,  then  it  creates  new  one. 

Paradox.dll  uses  the  Paradox  Engine  only.  Database  classes  work  with 

Paradox.dll.  This  hides  all  the  Paradox  implementations  into  the  database  objects. 

Application(s)  is  just  aware  of  an  object-oriented  database  implementation  as  a  front-end. 

The  database  objects  may  interface  any  DBMS. 
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Application 


Figure  16:  Database  development  file  organization 
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VII.  CONCLUSION  AND  FUTURE  WORKS  ON  FATDS 

A.     SUMMARY  AND  CONCLUSIONS 

This  thesis  concentrated  on  the  benefits  of  object-oriented  approach  over  FATDS  on 
sample  programming  implementations.  The  object-orientated  approach  mainly 
distinguishes  itself  form  the  other  conventional  ones  especially  in  two  phases:  Design  and 
maintenance.  Object-oriented  approach  offers  increased  modeling  power  to  represent  the 
real  world  in  a  problem  domain,  a  high  level  of  abstraction,  and  the  ability  to  inherit  and 
refine  object  properties.  Design  takes  the  greatest  portion  of  the  software  development 
cycle.  Maintenance  is  not  just  an  after-development-event,  but  a  continuing  phase  with  the 
design  during  the  software's  life-time  as  well. 

The  object-oriented  development  of  FATDS  is  accomplished  using  a  methodology 
namely  model-based  project  development  cycle.  This  methodology  depends  on  the  fact  that 
nothing  is  perfect  and  a  question  that  is  "is  this  what  you  want?".  A  development  of  a 
project  should  begin  somehow,  with  a  model  of  the  product.  The  model  is  a  prototype-like 
working  element  which  gives  an  idea  about  the  product  but  not  necessarily  a  completely 
functional  one.  This  model  provides  a  chance  to  evaluation  about  the  product  and  justifies 
the  rest  of  the  work.  Evaluation  causes  modifications  on  the  project.  The  inheritance, 
polymorphism  and  object  abstraction  features  of  object-oriented  approaches  facilitates  the 
modification  of  the  software  and  provides  faster  project  development  which  satisfies  the 
requirements  than  the  conventional  paradigms. 

By  promoting  code  reusability  the  object-oriented  paradigm  reduces  the  cost  and  time 
required  for  software  development.  In  order  to  exploit  the  reuse  and  portability  of  power  of 
0-0  approach,  design  plays  the  key  role.  Object-oriented  approach  does  not  differentiate 
itself  from  other  approaches  without  a  good  design.  Thus,  project  members  need  to  be 
experienced  on  OOA  and  OOD. 
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FATDS  has  the  following  features  which  make  to  work  with  object-oriented  approach 
more  beneficial  than  of  the  conventional  ones: 

•  Large-scale  systems. 

•  Modification  on  the  software  is  frequently  needed  with  new  concepts,  weapons, 
communication  systems  etc. 

•  FATDS  operators  are  short- termed  trained  on  that  system(s). 

•  Incorporates  a  diverse  large  and  distributed  database. 

At  the  beginning  of  a  object-oriented  software  development,  the  power  of  reuse  may 
not  put  itself  strong  since  there  may  not  be  much  objects  which  are  created  before.  As  the 
development  goes  on,  the  speed  of  project  development  increases  logarithmically. 

Advantages  of  object-oriented  databases  are  that  it  offers  the  designer  a  high  level  of 
flexibility  and  power  to  implement  arbitrarily  complex  and  operations. 

Object-oriented  database  structures  should  resemble  C++  or  some  other  object- 
oriented  language  program  structures  for  data  in  memory  (that  is,  the  equivalent  of  class 
instances  or  objects),  thereby  minimizing  discontinues  between  programming  and  database 
operations  and  structures.  A  good  OODBMS  must  be  a  full  object-oriented  database  system 
that  is  designed  to  support  large-scale  object  databases.  It  should  reflect  the  object 
paradigm  with  object  encapsulation  and  inheritance  of  both  data  and  functions.  [Ref.l: 
p.  169] 

B.      FUTURE  WORK 

The  programs,  both  the  OChart  and  OFire  are  not  completed  and  well-tested  for 
complete  functionality,  so  is  the  database  of  them.  The  followings  will  be  done  on  the 
programs: 

•  Firing  with  special  munitions 

•  Firing  with  met  +  MV. 

•  Interfacing  with  outer  devices. 

•  Creating  the  other  parts  of  the  firing  table  databases  and  for  other  guns  as  well. 
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To  continue  on  programming  development  increases  the  objects  which  are  created,  so 
does  the  reusability.  This  gives  more  reliable  bases  to  compare  object-oriented  paradigm 
with  the  others. 
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APPENDIX  A.  (OFERE  HEADER  FILES  LISTINGS) 

Listing  A.l:  BURSTS.H  header  file 

//it***************************************** 
// 

//  bursts. h 

// 

//  header  file  for  the  classes  BurstsWndCls 

//  SheafWndCls 


#ifndef     BURSTS_H 

#    define  BURSTS_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#include  "fire.h" 


#define  ID_CONVERGED  101 

#define  ID_PARALLEL   102 

#define  ID_SPECIAL    103 

#define  ID_OPEM       104 

#define  ID  GUNS       105 


_CLASSDEF (SheafWndCls ) 

_CLASSDEF (BurstsWndCls) 

//=================================================================== 

//  class  BurstsWndCls 

// 

//  Purpose   :  Displays  the  bursts  on  a  canvas  for*  each  gun  and  allows 

//  the  user  to  modify  them. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=================================================================== 

class  BurstsWndCls  :  public  TWindow 

{ 

private : 

RECT  WndRect ; 

PSheafWndCls  Sheaf Wnd; 

PButton2Cls  ButtonConverged; 

PButton2Cls  ButtonParallel; 

PButton2Cls  ButtonSpecial; 

PButton2Cls  ButtonOpen; 

HBITMAP  hBitmapl; //north  sign 

HBITMAP  hBmpLe ft Arrow ; 
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public : 

PTListBox 
BurstsWndCls 


-BurstsWndCls 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

virtual 

void 

}; 


ListGuns ; 

;PTWindowsObject  AParent, 
LPSTR  ATitle, 

int  X,  int  Y,  int  dX,  int  dY )  ; 

()  ; 

SetupWindow( ) ; 

Paint (HDC  PaintDC,  PAINTSTRUCT& 

ConvergedSheaf (RTMessage) 

ParallelSheaf (RTMessage) 

SpecialSheaf (RTMessage) 

OpenSheaf (RTMessage) 

Guns (RTMessage) 

DrawBorder (HDC  hDC,  int 

BOOL  isUp) ; 
UpdateList ( ) ; 
UpdateButtonArrow ( ) ; 
Updatelnf oArea ( ) ; 
UpdateSheafWindow ( ) ; 


[ID_FIRST 

+ 

ID 

CONVERGED 

[ID_FIRST 

+ 

ID 

.PARALLEL] 

[ID_FIRST 

+ 

ID 

.SPECIAL]  ; 

[ID_FIRST 

+ 

ID. 

.OPEN]  ; 

[ID_FIRST 

+ 

ID. 

.GUNS]  ; 

xl,  int  yl,  int  x2 ,  int  y2 , 


//  class 

// 

//  Purpose   :  Creates  a  canvas  for  BurstsWndCls  as  a  child  window, 

//  displays  the  bursts. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  SheafWndCls  :  public  TWindow 

{ 

private : 

RECT     WndRect; 

HCURSOR  hCursorTo; 

int      Cx; 

int      Cy; 

long     ScaleFactor ; 

public : 

SheafWndCls ( PTWindowsOb j ect  AParent , 

LPSTR  ATitle, 

int  X,  int  Y,  int  dX,  int  dY) ; 
-SheafWndCls ( ) ; 
virtual  LPSTR  GetClassName ( ) ; 
virtual  void   SetupWindow( ) ; 

virtual  void   Paint (HDC  PaintDC,  PAINTSTRUCT& ) ; 

virtual  void  WMLButtonDown (TMessage  &Msg) = [WM_FIRST  +WM_LBUTTONDOWN; 
virtual  void   WMSetCursor (TMessage  &)     = [WM_FIRST  +  WM_SETCURSOR] ; 


SheafWndCls 
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#endif    BURSTS  H 


Listing  A.2:  BUTTON2.H  header  file 


//••••••A************************************************************ 
// 

//  button2.h 

// 

//  header  file  for  Button2Cls  class 


#ifndef     BUTT0N2_H 

#    define  BUTT0N2_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#ifdef  BORLANDC 

//   PC-specific  includes 

#  include  <owl.h> 

#  include  <button.h> 
#endif 


#ifdef  Unix 

//    UNIX-specific  includes 

#endif 


_CLASSDEF ( But  t on2C 1 s ) 

//=================================================================; 

II    class  Button2Cls 

// 

//  Purpose  :  Creates  a  custom  button.  It  inherits  all  the  behavior 

//  TButton  class  and  adds  the  following  features: 

//  >It  has  a  constant  background. 

//  >It  may  be  instantiated  with  atmost  two  bitmap 

//  resource  name,  if  it  is  intanctiated  with  two 

//  bitmaps,  it  displays  the  first  one  regularly  and 

//  displays  the  second  one  when  the  button  clicked. 

//  If  it  is  instantiated  with  one  bitmap  only,  then 

//  it  displays  that  bitmap  for  all  occassions. 

//  It  may  be  instantiated  with  no  bitmaps. 

//  >Bitmap  is  displayed  on  the  right  of  button  while 

//  the  text  is  on  the  left. 

// 

//  Notes  :  The  size  of  bitmap  file  should  be  smaller  than  the 

//  button  sizes.  Otherwise  the  bitmap  is  clipped. 

// 


//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 
//  All  Rights  Reserved 
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class  Button2Cls  :  public  TButton 

{ 
private : 

char  Text [80]  ; 
RECT  BRect; 
HBITMAP  hBitmapl; 
HBITMAP  hBitmap2; 

protected: 

virtual  void  ODADrawEntire (DRAWITEMSTRUCT  _FAR  &  Drawlnfo); 
virtual  void  ODAFocus (DRAWITEMSTRUCT  _FAR  &  Drawlnfo); 
virtual  void  ODASelect (DRAWITEMSTRUCT  _FAR  &  Drawlnfo); 
virtual  void  DrawFrame ( HDC  hDC,  RECT  Rect,  BOOL  Selected); 
virtual  void  WriteText (HDC  hDC,  LPSTR  Text); 
virtual  void  PutBitmap (HDC  hDC,  BOOL  Pressed  =  FALSE); 

public : 

Button2Cls ( PTWindowsObject  AParent , 


int 

Anld, 

LPSTR 

AText , 

LPSTR 

BitmaplName, 

LPSTR 

Bitmap2Name, 

int 

X, 

int 

Y, 

int 

w, 

int 

H, 

BOOL 

IsDefault , 

PTModule 

AModule  =  NULL 

-Button2Cls 


}; 


#endif    BUTTON2  H 


Listing  A.3:  COMMAND.H  header  file 


//••it********************************* 
// 

//  command. h 

// 

//  header  file  for  CommandWndCls , 

//  FireCommandsWndCls , 

//  InfoWndCls, 

//  SubFireCallWndCls,  and 

//  ChronoWndCls  classes 


#ifndef 

#    define 


_COMMAND_H 
COMMAND  H 


//note  that  the  following  code  is  executed  only 
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//if  this  file  has  not  been  previously  included 


#include  "fire.h" 


ttdefine  MAXVLINE  6 

#define  MAXHLINE  8 

#define  ID_SEND  100 

#define  ID_FIRE  101 

#define  ID_INFO  201 

#define  ID_FIRECOMMANDS  301 

#define  ID_SUBFIRECALL  401 

#define  ID_CHRONO  501 

#define  ID_WHENREADY  502 

#define  I D_ATMY COMMAND  503 

#define  ID_ATTIME  504 

#define  ID  AFTERTIME  505 


_CLASSDEF (CommandWndCls) 

_CLASSDEF (FireCommandsWndCls) 

_CLASSDEF ( Inf oWndCls ) 

_CLASSDEF(SubFireCallWndCls) 

_CLASSDEF(ChronoWndCls) 

//================================================================== 

//  class  CommandWndCls 

// 

//  Purpose   :  Hosts  the  other  child  windows. 

// 

//  Notes     :  It  has  one  more  constructure  which  is  encapsulated  as 

//  protected.  It  is  suppossed  to  be  used  only  by  its  sub 

/ /  classes . 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//================================================================== 

class  CommandWndCls  :  public  TWindow 

{ 

private : 


RECT  WndRect ; 

PFireCommandsWndCls  FireCommandsWnd; 

PlnfoWndCls  InfoWnd; 

PSubFireCallWndCls  SubFireCallWnd; 

PChronoWndCls  ChronoWnd; 

PButton2Cls  ButtonSend; 

PButton2Cls  ButtonFire; 

PButton2Cls  ButtonFireCommands; 

PButton2Cls  Buttonlnfo; 

PButton2Cls  ButtonSubFireCall; 

PButton2Cls  ButtonChrono; 

public : 

CommandWndCls ( PTWindowsOb j ect  AParent , 
LPSTR  ATitle, 
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int 
int 
int 
int 


X, 
Y, 
dX, 
dY)  ; 


-CommandWndCls ( ) ; 
virtual  void  SetupWindow( ) ; 
virtual  void  Paint (HDC  PaintDC, 
virtual  void  Send (RTMessage) 
virtual  void  Fire (RTMessage) 
virtual  void  FireCommands (RTMessage) 
virtual  void  Info (RTMessage) 
virtual  void  SubFireCall (RTMessage) 


PAINTSTRUCT&) ; 

=  [ID_FIRST 

=  [ID_FIRST 

[ID_FIRST 

[ID_FIRST 

[ID_FIRST 


virtual  void  Act ivateChronometer ( long  dT) ; 

protected : 

CommandWndCls ( PTWindowsOb j ect  AParent , 
LPSTR  ATitle) ; 

}; 


+  ID_SEND] ; 

+  ID_FIRE] ; 

+  ID_FIRECOMMANDS] 

+  ID_INFO] ; 

+  ID_SUBFIRECALL] ; 


//  class 

// 

//  Purpose 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


FireCommandsWndCls 
Display  fire  commands  for  each  gun  which  is  to  fire 


class  FireCommandsWndCls  :  public  TWindow 

{ 

private : 

RECT   WndRect; 

int    VLine [MAXVLINE-1 ] ; //x  coordinates  of  vertical  lines/borders 

int    HLine [MAXHLINE+1 ] ; / /y  coordiantes  of  horizantal  lines/borders 

public: 

FireCommandsWndCls ( PTWindowsObj ect  AParent , 

LPSTR        •  ATitle, 

int  X, 

int  Y, 

int  dX, 

int  dY) ; 
-FireCommandsWndCls ( ) ; 
virtual  void  SetupWindow ( ) ; 
virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCT& ) ; 


//  class 

// 

//  Purpose 

// 


InfoWndCls 

Displays  fire  call,  fire  order  and  message  to  observer 
messages  after  they  have  been  set . 
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// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  InfoWndCls  :  public  TWindow 

{ 
private : 

RECT  WndRect; 

public : 

InfoWndCls ( PTWindows Object  AParent , 
LPSTR  ATitle, 

int  X,  int  Y,  int  dX,  int  dY) ; 
-InfoWndCls ( ) ; 
virtual  void  SetupWindow () ; 

virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCT&) ; 
}; 


II    class  SubFireCallWndCls 

// 

//  Purpose   :  Displays  subsequent  fire  calls. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=============================================; 

class  SubFireCallWndCls  :  public  TWindow 

{ 

private : 


RECT  WndRect; 

public : 

SubFireCallWndCls (PTWindowsObject  AParent, 

LPSTR  ATitle, 

int  X,  int  Y,  int  dX,  int  dY) ; 

-SubFireCallWndCls ( ) ; 

virtual  void  SetupWindow () ; 

virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCT&) ; 
}; 


II    class  ChronoWndCls 

// 

//  Purpose   :  Displays  a  digital  chronometer  for  seting  the  firing 

//  time.  It  also  instantiates  the  firing  if  it  is  a  timed 

//  firing. 

// 

//  Notes     :  Windows  3.1  allows  only  16  clocks  to  work  simultaneously, 

//  each  OFIRE  program  executes  one  already. 
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// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 
//  All  Rights  Reserved 


class  ChronoWndCls  :  public  Window 

{ 
private : 


PTBRad 

ioButt 

on 

RadioWhenReady ; 

PTBRad 

ioButt 

on 

RadioAtMy Command ; 

PTBRad 

ioButt 

on 

RadioAtTime; 

PTBRad 

ioButt 

on 

RadioAf terTime ; 

RECT 

WndRect ; 

WORD 

wTimer ; 

WORD 

wElapse; 

long 

dTime; 

int 

Hour  ; 

int 

Minute; 

int 

Second; 

public : 


ChronoWndCls ( PTWindowsObj  ect  AParent , 
LPSTR  ATitle, 

int  X, 

int  Y, 

int  dX, 

int  dY) ; 

-ChronoWndCls ( ) ; 
virtual  void  SetupWindow ( ) ; 
virtual  void  Paint (HDC  PaintDC, 
virtual  void  WMTimer (RTMessage) 
virtual  void  WhenReady (RTMessage) 
virtual  void  AtMy Command (RTMessage) 
virtual  void  AtTime (RTMessage) 
virtual  void  Af terTime (RTMessage) 
virtual  void  StartCountDown ( long  dT 


PAINTSTRUCT& ) ; 
=  [WM_FIRST 

)  =  [ID_FIRST 
[ID_FIRST 
[ID_FIRST 
[ID_FIRST 


+  WM_TIMER] ; 

+  ID_WHENREADY] ; 

+  ID_ATMYC0MMA1\ID] 

+  ID_ATTIME] ; 

+  ID  AFTERTIME] ; 


#endif 


COMMAND  H 


Listing  A.4:  FIRE.H  header  file 


// 

//  fire.h 

// 

//  header  file  for  dialog  class  declerations  which  are: 

//  FireCallDlgCls, 

//  PolarWndCls, 

//  ShiftWndCls, 

//  GridWndCls, 

//  SuppressionWndCls, 

//  FireOrderDlgCls, 

//  MTODlgCls, 

//  SubFireCallDlgCls, 
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//  TOTAtTimeDlgCls, 

//  TOTAfterTimeDlgCls . 


#ifndef     FIRE H 

#    define  FIRE H 


#ifdef  BORLANDC 

//  PC-specific  includes 

#  include  <owl.h> 

#  include  <edit.h> 

#  include  <listbox.h> 

#  include  <combobox.h> 

#  include  <scrollba.h> 

#  include  <dialog.h> 

#  include  <bwcc.h> 

#  include  <button.h> 

#  include  <string.h> 

#  include  <bchkbox.h> 

#  include  <bradio.h> 
#endif 


#ifdef  Unix 

//    UNIX-specific  includes 

#endif 


#include  "button2.h" 
#include  "dbtarget.h" 
# include  "dbgun.h" 


//firecall  dialog 

#define  ID_FIREORDER  106 

#define  ID_VIEW  105 

#define  ID_FROM  107 

#define  ID_MISSIONTYPE  108 

#define  ID_SIZE  109 

#define  ID_POLAR  110 

#define  ID_SHIFT  111 

#define  ID_GRID  112 

#define  ID_SUPPRESSION  113 

#define  ID_DESCRIPTION  129 

#define  ID_TARGETNO  111 

#define  ID_DIRECTION  101 

#define  ID_DISTANCE  102 

#define  ID_UPDOWN  103 

#define  ID_SHIFTFROM  104 

#define  ID_RIGHTLEFT  105 

#define  ID_ADDDROP  10  6 

#define  ID_ZONE  107 

#define  ID_EAST  108 
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#define  ID_NORTH  109 

#define  ID_HEIGHT  110 

//mto  dialog 

#define  ID_MT0  101 

#define  ID_PROCESS  110 

#define  ID_UNITTOFIRE  107 

#define  ID_GUNLIST  119 
#define  ID_ADJUSTINGELEMENT  108 

//sub-fire  call  dialog 

#define  ID_DEVIATION  101 

#define  ID_DISTANCE  102 

#define  ID_H0B  103 

#define  ID_H0UR  701 

#define  ID_MINUTE  702 

#define  ID  SECOND  703 


_CLASSDEF ( PolarWndCls ) 
_CLASSDEF(ShiftWndCls) 
_CLASSDEF(GridWndCls) 
_CLASSDEF ( Suppr es  s  ionWndC 1 s 

//=========================: 


//  class  FireCallDlgCls 

// 

//  Purpose   :  Demonstrates  FireCall  dialog  box 

// 

//  Notes     :  It  work  with  Paradox  Engine,  make  sure  related  *.dll 

//  files  are  on  path. 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


class  FireCallDlgCls  :  public  TDialog 

{ 

private : 

RECT  cWnd; 

PPolarWndCls  PolarWnd; 

PShiftWndCls  ShiftWnd; 

PGridWndCls  GridWnd; 
PSuppressionWndCls  Suppress ionWnd; 

PTComboBox  ComboFrom; 

PTComboBox  ComboType ; 

PTComboBox  ComboSize; 


//source  of  fire  call 

//type  of  mission 

//size  of  element  for  effect 


public : 

FireCallDlgCls ( PTWindowsObj ect  AParent, 

LPSTR  AName) ; 

-FireCallDlgCls ( ) ; 
virtual  void  SetupWindow ( ) ; 
virtual  void  RadioPolar (RTMessage) 
virtual  void  RadioShift (RTMessage ) 
virtual  void  RadioGrid (RTMessage) 
virtual  void  RadioSuppression (RTMessage) =[ ID_FIRST  +  ID_SUPPRESSION] 
virtual  void  ButtonOrder (RTMessage)      =  [ID_FIRST  +  ID_FIREORDER] ; 
virtual  void  ButtonView (RTMessage)       =  [ID_FIRST  +  ID_VIEW] ; 
virtual  void  UpdateFrom ( ) ; 


=[ID_FIRST  +  ID_POLAR] ; 
=[ID_FIRST  +  ID_SHIFT] ; 
=[ID_FIRST  +  ID_GRID] ; 
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}; 


virtual  void  UpdateSize ( ) ; 
virtual  void  UpdateType ( ) ; 
virtual  void  UpdateTargetDatabase 


//  class 

// 

//  Purpose 

// 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


PolarWndCls 

Child  window  for  FireCallDlgCls . 
Displays  polar  location  type  controls 


class  PolarWndCls  :  public  TWindow 

{ 
private : 

RECT    WndRect ; 
PTEdit  EditDirection; 
PTEdit  EditDistance; 
PTEdit  EditUpDown; 


public 


PolarWndCls ( PTWindowsObject  AParent, 
LPSTR  ATitle, 

int ,  int ,  int ,  int ) ; 

-PolarWndCls ( ) ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Paint (HDC  hDC,  PAINTSTRUCT  & )  ; 

virtual  void  SetLocValues ( ) ; 


II    class 

// 

//  Purpose   :  Child  window  for  FireCallDlgCls. 

//  Displays  shift  location  type  controls 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=================================================: 

class  ShiftWndCls  :  public  TWindow 

{ 

private : 


ShiftWndCls 


RECT 

PTComboBox 

PTEdit 

PTEdit 

PTEdit 


WndRect ; 
ComboFrom; 
EditDirection ; 
EditRightLeft; 
EditAddDrop; 
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PTEdit        EditUpDown; 
PDBTargetCls  DBTargets; 


public 


Shif tWndCls ( PTWindowsObject  AParent , 

LPSTR  ATitle, 

int,  int,  int,  int) ; 
-ShiftWndCls ( ) ; 
virtual  void  SetupWindow( ) ; 

virtual  void  Paint (HDC  hDC ,  PAINTSTRUCT  &) ; 

virtual  void  TargetNo (RTMessage)  =  [ID_FIRST  +  ID_SHIFTFROM] 
virtual  void  SetLocValues ( ) ; 
virtual  BOOL  UpdateComboFrom ( ) ; 


II    class 

// 

//  Purpose   :  Child  window  for  FireCallDlgCls . 

//  Displays  grid  location  type  controls 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


GridWndCls 


class  GridWndCls  :  public  TWindow 

{ 
private : 

RECT    WndRect ; 
PTEdit  EditZone; 
PTEdit  EditEast; 
PTEdit  EditNorth; 
PTEdit  EditAltitude; 
PTEdit  EditDirection; 

public : 

GridWndCls (PTWindowsObject  AParent, 
LPSTR  ATitle, 

int,  int,  int,  int);- 
-GridWndCls ( )  ; 
virtual  void  SetupWindow( ) ; 
virtual  void  Paint (HDC  hDC,  PAINTSTRUCT 
virtual  void  SetLocValues ( ) ; 
}; 


&) 


//  class 

// 

//  Purpose 

// 

// 

//  Notes 

// 


Suppre  s  s  ionWndC 1 s 

Child  window  for  FireCallDlgCls. 

Displays  suppression  location  type  controls 
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//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 
//  All  Rights  Reserved 


class  SuppressionWndCls  :  public  Window 
{ 


private 


RECT 

char 

long 

long 

long 

PTComboBox 

PTEdit 

PDBTargetCls 

char 


WndRect ; 
Zone [  5  ]  ; 
East  ; 
Norths- 
Height; 

ComboTargetNo ; 
EditDirection; 
DBTargets; 
Description [80 ' 


public 


SuppressionWndCls (PTWindowsObject  AParent , 

LPSTR  ATitle, 

int,  int ,  int ,  int )  ; 
-SuppressionWndCls ( ) ; 

virtual  void   SetupWindow( ) ; 

virtual  void   Paint (HDC  hDC,  PAINTSTRUCT  &) ; 

virtual  void   TargetNo (RTMessage)  =  [ID_FIRST  +  ID_TARGETNO] ; 

virtual  void   SetLocValues ( ) ; 

virtual  BOOL   UpdateComboTargetNo ( ) ; 

virtual  char  *GetTargetDescription ( ) ; 


//========= 

//  class 

// 

//  Purpose 

// 

//  Notes     :  It  work  with  Paradox  Engine,  make  sure  related  *.dll 

//  files  are  on  path. 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


FireOrderDlgCls 
Demonstrates  FireOrder  dialog  box 


class  FireOrderDlgCls  :  public  TDialog 

{ 

private : 


int 

int 

char 

long 

long 

long 

PTComboBox 

PTListBox 

PTButton 

PDBGunCls 


MainGun; 
GunNo [ 8 ] ; 
Zone  [  8 ]  [  3  ]  ; 
East  [8]  ; 
North [8]  ; 
Height [8]  ; 
ComboUnitToFire ; 
ListGuns ; 

ButtonAdjustingElement ; 
DBGuns ; 


public 
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FireOrderDlgCls ( PTWindowsObject  AParent , 

LPSTR  AName) ; 

-FireOrderDlgCls ( ) ; 
virtual  void  SetupWindow () ; 

virtual  void  MTO (RTMessage)  =[ID_FIRST  +  ID_MTO] ; 

virtual  void  ProcessForFire (RTMessage )   =[ID_FIRST  +  ID_PROCESS ] ; 
virtual  void  UnitToFire (RTMessage)       =[ID_FIRST  +  ID_UNITTOFIRE] ; 
virtual  void  AdjustingElement (RTMessage) =[ ID_FIRST  + 

ID_ADJUSTINGELEMENT] ; 
virtual  BOOL  UpdateComboUnitToFire ( ) ; 
virtual  BOOL  UpdateListGuns ( ) ; 
virtual  void  CollectData ( ) ; 


//================================================================: 

//  class  MTODlgCls 

// 

//  Purpose   :  Demonstrates  message  to  observer  dialog  box 

// 

//  Notes     :  It  work  with  Paradox  Engine,  make  sure  related  *.dll 

//  files  are  on  path. 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//================================================================ 

class  MTODlgCls  :  public  TDialog 

{ 
public : 


MTODlgCls (PTWindowsObject  AParent, 

LPSTR  AName) ; 

-MTODlgCls ( ) ; 
virtual  void  SetupWindow ( ) 

{} 

virtual  void  Ok (RTMessage)        =  [ID_FIRST  +  IDOK] ; 

virtual  void  Cancel (RTMessage)    =  [ID_FIRST  +  IDCANCEL; 


// ================================================================ 

//  class  SubFireCallDlgCls 

// 

//  Purpose   :  Demonstrates  subfire  call  dialog  box 

// 

//  Notes     :  It  work  with  Paradox  Engine,  make  sure  related  *.dll 

//  files  are  on  path. 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//================================================================: 

class  SubFireCallDlgCls  :  public  TDialog 

{ 

private : 


PTEdit    EditDeviation; 
PTEdit    EditDistance; 
PTEdit    Ed it HOB; 
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PTButton  ButtonProcess ; 


public 


SubFireCallDlgCls ( PTWindowsObj ect  AParent , 

LPSTR  AName) ; 

-SubFireCallDlgCls ( ) ; 

virtual  void  Process (RTMessage)   =  [ID_FIRST  +  ID_PROCESS] ; 
virtual  void  Cancel (RTMessage)    =  [ID_FIRST  +  IDCANCEL]; 
virtual  void  Help (RTMessage)      =  [ID_FIRST  +  IDHELP] ; 


//  class 

// 

//  Purpose 

// 

//  Notes     :  It  work  with  Paradox  Engine,  make  sure  related  *.dll 

//  files  are  on  path. 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  TOTAtTimeDlgCls  :  public  TDialog 

{ 

private : 

PTEdit    EditHour; 
PTEdit    EditMinute; 
PTEdit    EditSecond; 

public : 

TOTAtTimeDlgCls ( PTWindowsObj  ect  AParent , 


TOTAtTimeDlgCls 
Demonstrates  (time  on  target)  At  Time  dialog  box 


LPSTR 
-TOTAtTimeDlgCls  (  )  ; 
virtual  void  SetupWindowf ) ; 
virtual  void  Ok (RTMessage) 
virtual  void  Cancel (RTMessage! 
virtual  void  Help (RTMessage) 


AName' 


=  [ID_FIRST  +  IDOK] ; 

=  [ID_FIRST  +  IDCANCEL ; 

=  [ID_FIRST  +'  IDHELP]; 


TOTAfterTimeDlgCls 


I /    class 

// 

//  Purpose   :  Demonstrates  (time  on  target)  After  Time  dialog  box 

// 

//  Notes     :  It  work  with  Paradox  Engine,  make  sure  related  *.dll 

//  files  are  on  path. 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  TOTAfterTimeDlgCls  :  public  TDialog 

{ 

private : 
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PTEdit    EditHour; 
PTEdit    EditMinute; 
PTEdit    EditSecond; 

public : 

TOTAf terTimeDlgCls ( PTWindowsObject  AParent ,  LPSTR  AName ) ; 
-TOTAf terTimeDlgCls ( ) ; 
virtual  void  SetupWindow ( ) ; 

virtual  void  Ok (RTMessage)      =  [ID_FIRST  +  IDOK] ; 
virtual  void  Cancel (RTMessage)  =  [ID_FIRST  +  IDCANCEL] ; 
virtual  void  Help (RTMessage)    =  [ID_FIRST  +  IDHELP] ; 
}; 


#endif    FIRE   H 


Listing  A.5:  GLOBALS.H  header  file 


// 

//  globals.h 

// 

//    header    file    for   global    variables,    objects    and 

//  ComputationCls 

//**  +  *  +  *******************************  +  ************■****************** 


#ifndef     GLOBALS H 

#    define    GLOBALS   H 


#include  <string.h> 
#include  "dbtbl  f.h" 


#define  SUCCESS  1 
#define  FAIL     0 


enum  MissionType   {mADJUSTFIRE, 

mFIREFOREFFECT, 
mSUPPRESSION, 
mIMMEDIATESUPPRESSION, 
mIMMEDIATESMOKE} ; 

enum  LocationType  {POLAR, 

SHIFT, 
GRID, 
SUPPRESSION} ; 

enum  Sheaf Type     {CONVERGED, 

PARALLEL , 
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SPECIAL, 
OPEN) ; 

enum  TimingType    {WHENREADY, 

ATMYCOMMAND, 
ATTIME, 
AFTERTIME} ; 


//struct  Gun 

// 

//  Purpose   :  Holds  information  for  a  gun 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=============================================== 

struct  Gun 
{ 

int     GunNo; 

//gun  location 
char    Zone [  5  ]  ; 
double  East; 
double  North; 
double  Height; 

//firing  command  elements 
double  Timing; 
double  Deflection; 
double  Elevation; 
double  Quadrant; 

//target-hit  info 

char    HitZone [5] ; 

double  HitEast; 

double  HitNorth; 

double  HitHeight; 

double  HitRange; 

double  HitDef lection;  //chart  deflection 

double  HitAzimuth;     //gun-hit  point  azimuth 

//gun  general  info 
double  CommonOr ientat ion ; 
}; 


//_CLASSDEF(ComputationCls) 

//  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  ^  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =;;;  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  ===  =  =  =  =  =  =  =  = 

//  class  ComputationCls 

// 

//  Purpose   :  Makes  all  the  computations  for  a  gun  battery  fire  direction 

// 

//  Notes     :  It  works  with  Paradox  Engine,  so  necessary  *.dll  files 

//  should  be  on  path. 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 
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class  ComputationCls 

{ 

private : 

WStr  FiringTableName; 

WStr  FiringCharge ; 

PDBTable_F_Cls  DBTable_F; 

public : 

char  BatteryName [ 3 ] ; 

char  CallLine[4] [80] ; 

char  OrderLine [80] ; 

char  MTOLine[80] ; 

char  SubCallLine[50] ; 

//observer  information 
char    ObserverName [ 10 ] ; 
char    ObserverZone [ 10 ] ; 
double  ObserverEast ; 
double  ObserverNorth; 
double  ObserverHeight ; 
double  OTDirection; 

//target  location  before  adjustment 

char    IniTargetZone [3 ] ; 

double  IniTargetEast ; 

double  IniTargetNorth; 

double  IniTargetHeight ; 

double  IniTargetRange;      //for  main  gun 

double  IniTargetDef lection; //for  main  gun 

//target  location  after  adjustment 

char    CurrTargetZone [3 ] ; 

double  CurrTargetEast ; 

double  CurrTargetNorth; 

double  CurrTargetHeight ; 

//target  location  settings 

// 

/ /polar 

double  PolarDistance ; 

double  PolarUpDown; 

// 

//grid 

char    GridZone [3 ] ; 

double  GridEast; 

double  GridNorth; 

double  GridHeight; 

// 

//shift 

char    ShiftFrom[10] ; 

char    ShiftZone[10] ; 

double  ShiftEast; 

double  ShiftNorth; 

double  ShiftHeight; 

double  ShiftRightLeft; 

double  ShiftAddDrop; 

double  ShiftUpDown; 

// 

//suppression 

char    SuppTargetNo[10] ; 
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char    Description [ 128] ; 

char    Category [80] ; 

//fire  command  settings 
int  NoOf PiecesToFollow; 


//current  values 


char 

char 

char 

Locat ionType 

SheafType 


CurrFrom[10] ; 
CurrMiss ionType [ 50]  ; 
CurrSize  [10] ; 
CurrLocat  ionType ; 
CurrSheaf ; 


//gun  parameters 
Gun     Guns [8]  ; 
int     MainGun; 
double  AzimuthOf Fire; 

//gun  -  ammo 

double  BurstDiameter ; 

//fire  commands  buffers 
int  FiredNo; 

ComputationCls ( ) ; 
-ComputationCls ( ) ; 


virtual  void 
virtual  void 
virtual  void 


virtual  void 


void  SetFiri 
WStr  GetFiri 
BOOL  Compute 
BOOL  Compute 
BOOL  Compute 

void  Reset ( 


ComputeHitCoors ( ) ; 
ComputeChart Values ( ) ; 
ComputeRangeAzimuth (double   xl, 

double   yl, 
double   x2 , 
double   y2, 
double  &Range, 
double  ^Azimuth) ; 
ComputeCoordinate (double   xl, 

double   yl, 
double   Range, 
double   Azimuth, 
double  &x2 , 
double  &y2 ) ;    ' 
ngTableName (WStr  FTName ) ; 
ngCharge ( ) ; 
FiringCharge ( ) ; 
Elevations ( ) ; 
FiringValues ( ) ; 


}; 


#endif 


GLOBALS   H 


Listing  A.6:  REPORT.H  header  file 

// 
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//  report . h 

// 

//  header  file  for  the  classes  ReportWndCls , 

//  TextWndCls 

//••••••••••••it*************** 


#ifndef     REPORT_H 

#    define  REPORT_H 

//  Note  the  following  code  is  only  executed  if 
//  this  file  has  not  been  previously  included 


#include  "fire.h" 


#define  ID  PRINT  101 


_CLASSDEF ( Repor tWndC 1 s ) 

_CLASSDEF ( TextWndC 1 s ) 

//================================================================= 

//  class  ReportWndCls 

// 

//  Purpose   :  Hosts  a  canvas  window  which  displays  the  firig  report 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=:=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  = 

class  ReportWndCls  :  public  TWindow 

{ 

private : 


RECT  WndRect ; 
PTextWndCls  TextWnd; 
PButton2Cls  ButtonPrint; 


public : 


ReportWndCls ( PTWindowsObj  ect  AParent , 

LPSTR  ATitle, 

int  X, 

int  Y, 

int  dX, 

int  dY)  ; 

-ReportWndCls ( ) ; 
virtual  void  SetupWindow ( ) ; 

virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCT& ) ; 
virtual  void  Print (RTMessage)   =  [ID_FIRST  +  ID_PRINT] 
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//  class  TextWndCls 

// 

//  Purpose   :  Serves  as  a  canvas  to  display  the  firing  report 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//===========================================================: 

class  TextWndCls  :  public  TWindow 

( 

private : 

RECT         WndRect; 

public : 

TextWndCls ( PTWindowsObj  ect  AParent , 

LPSTR  ATitle, 

int  X, 

int  Y, 

int  dX, 

int  dY) ; 

-TextWndCls ( ) ; 
virtual  void  SetupWindow ( ) ; 

virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCT& ) ; 
}; 


#endif    REPORT  H 


Listing  A.7:  SELECT.H  header  file 


// 

//  select  .h 

// 

//  header  file  for  the  class  SelectionWndCls 


#ifndef     SELECT_H 

#    define  SELECT_H 

//  Note  the  following  code  is  only  executed  if 
//  this  file  has  not  been  previously  included 


#include  "fire.h" 
# include  " command. h' 
#include  "bursts. h" 
# include  " report. h" 
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#define  ID_EXIT  101 
#define  ID  HELP  102 


//from  fire.cpp 

extern  PCommandWndCls  CommandWnd; 
extern  PBurstsWndCls   BurstsWnd; 
extern  PReportWndCls   ReportWnd; 


_CLASSDEF(SelectionWndCls) 
//=================================================================== 

//  class  SelectionWndCls 

// 

//  Purpose   :  Displays  notebook  tab-stops  to  select  different  windows 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


//===================================== 

class  SelectionWndCls  :  public  TWindow 

{ 
private : 

PTWindowsObject  MainWnd; 


RECT 

POINT 

short 

PButton2Cls 

PButton2Cls 


WndRect ; 
IndexTab[3] [4; 
CurrlndexTab; 
ButtonExit ; 
ButtonHelp; 


public 


SelectionWndCls (PTWindowsObject  AParent , 

LPSTR  ATitle, 

int  X, 

int  Y, 

int  dX, 

int  dY)  ; 

-SelectionWndCls ( ) ; 
virtual  void  SetupWindow( ) ; 

virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCTk ) ; 
virtual  void  WMLButtonDown (TMessage  &)  =  [WM_FIRST 
virtual  void  Exit (RTMessage)  =  [ID_FIRST 

virtual  void  Help (RTMessage)  =  [ID_FIRST 


+  WM_LBUTTONDOWN] 
+  ID_EXIT] ; 
+  ID_HELP] ; 


#endif 


91 


APPENDIX  B.  (OCHART  HEADER  FILES  LISTINGS) 

Listing  B.l:  ABSLIST.H  header  file 

// 

//  abslist .h 

// 

//  header  file  for  the  class  genAbstractList 

//**********************•***************•**************************** 


#ifndef     _ABSLIST_H 
#    define  _ABSLIST_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#define  ALLOCATE_ERROR  "Dynamic  allocation  error" 

enum  boolean  {  false,  true  } ; 
typedef  char  string80 [81 ] ; 


//================================================================ 

//  template  class  genAbstractList 

// 

//  Purpose   :  implements  an  abstract  class  of  linked  lists  with 

//  the  following  operations  and  features: 

// 

//  >  nodes  with  duplicate  keys  can  be  allowed. 

//  >  insert  new  node. 

//  >  search  for  a  node  with  a  specif ic< occurrence 

//  of  a  key. 

//  >  delete  a  node  with  a  specific  occurrence  of  a  key 

//  >  traverse  the  nodes  of  the  lists. 

//  the  user  to  modify  them. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//===============================================================; 

template<class  T> 
class  genAbstractList 
{ 
protected: 

unsigned  listSize;  //  number  of  nodes 

boolean   overwrite;  //  overwrite  data  flag 

boolean   hasDuplicate;  //  duplicate-key  flag 

string80  errorMessage ;  //  error  message 
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public 


//state  query  methods 
boolean  isEmpty() 

{ 

return  (listSize  ==  0)  ?  true  :  false, 
} 


unsigned  getListSize 

{ 

return  listSize; 

} 


char*  getErrorMessage ( ) 
{ 

string80  s; 

strcpy(s,  errorMessage); 

errorMessage [ 0]  =  '\0'; 

return  s ; 
} 


//object  manipulation  methods 

genAbstractList ( ) 

{} 


virtual  boolean  insert (T&! 
{ 

return  false; 
} 


virtual  boolean  remove (T&,  unsigned  occur  -    1) 
{ 

return  false; 

} 


virtual  boolean  search(T&,  unsigned  occur  =  1) 
{ 

return  false; 
} 


virtual  boolean  visitFirstNode (T&i 
{ 

return  false; 
} 
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virtual  boolean  visitNextNode (T&] 

{ 

return  false; 
} 


virtual  void  clear ( 
{} 


}; 


#endif   ABSLIST  H 


Listing  B.2:  CHART.H  header  file 


//*****************•***************************** 

// 

//  chart. h 

// 

//  header  file  the  classes  GridSetupDlgCls 

//  TargetSetupDlgCls 

//  GunSetupDlgCls 

//  NewEntryDlgCls 

//  NewFromEntryDlgCls 

//  GunlnputDlgCls 

//  TargetlnputDlgCls 

//  TargetDBDlgCls 

//  GunDBDlgCls 


#ifndef     CHART_H 

#    define  CHART_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#include  <owl.h> 

#include  <edit.h> 

#include  <listbox.h> 

# include  <combobox.h> 

#include  <dialog.h> 

# include  <bwcc.h> 

#include  <button.h> 

#include  <string.h> 

#include  <static.h> 

#include  <scrollba.h> 

#include  <bchkbox.h> 

#include  <bradio.h> 

#include  "defines. h" 

#include  "globals.h" 
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#include  "targetdb.h" 
#include  "gundb.h" 


//  class  GridSetupDlgCls 

// 

//  Purpose   :  Displays  grid  setup  dialog  box. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  GridSetupDlgCls  :  public  TDialog 

{ 

private : 

PTEdit      Ed it Zone; 
PTEdit      EditLeft; 
PTEdit      EditRight; 
PTEdit      EditBottom; 
PTEdit      Ed it Top; 
PTComboBox  CoraboDistance ; 
PTComboBox  ComboScale; 
PTCheckBox  CheckShowGrid; 
PTCheckBox  CheckShowNorth; 

public : 

GridSetupDlgCls ( PTWindowsObject  AParent,  LPSTR  AName); 

-GridSetupDlgCls ( ) ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Ok (RTMessage)  -    [ID_FIRST  +  IDOK] ; 

virtual  void  Cancel (RTMessage)         =  [ID_FIRST  +  IDCANCEL] 

virtual  void  Help (RTMessage)  =  [ID_FIRST  +  IDHELP] ; 


II    class  TargetSetupDlgCls 

// 

//  Purpose   :  Displays  target  setup  dialog  box. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//============================================= 

class  TargetSetupDlgCls  :  public  TDialog 

{ 

private : 


PTCheckBox  CheckShowTargets ; 

public : 

TargetSetupDlgCls (PTWindowsObject  AParent,  LPSTR  AName); 
-TargetSetupDlgCls ( ) ; 


95 


virtual  void  SetupWindow( ) ; 
virtual  void  Ok (RTMessage) 
virtual  void  Cancel (RTMessage) 
virtual  void  Help (RTMessage) 


=  [ID_FIRST  +  IDOK] ; 
=  [ID_FIRST  +  IDCANCEL; 
=  [ID_FIRST  +  IDHELP]; 


//======================: 

//  class 

// 

//  Purpose   :  Displays  gun  setup  dialog  box. 

// 

//  Notes      : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//============================================================== 

class  GunSetupDlgCls  :  public  TDialog 

{ 

private : 

PTComboBox  ComboScale; 
PTCheckBox  CheckShowCoverings ; 

public : 

GunSetupDlgCls (PTWindowsObject  AParent ,  LPSTR  AName ) ; 

-GunSetupDlgCls  (  )  ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Ok (RTMessage)  =  [ID_FIRST  +  IDOK]; 

virtual  void  Cancel (RTMessage)         =  [ID_FIRST  +  IDCANCEL] 

virtual  void  Help (RTMessage)  =  [ID_FIRST  +  IDHELP]; 


GunSetupDlgCls 


//======================. 

//  class 

// 

//  Purpose   :  Displays  new  entry  dialog  box. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

// ============================================= 

class  NewEntryDlgCls  :  public  TDialog 

{ 

protected : 


NewEntryDlgCls 


long  NewX; 

long  NewY; 

PTRadioButton  RadioTarget ; 
PTRadioButton  RadioGun; 
PTRadioButton  RadioRadar; 
PTRadioButton  RadioObservat ionPost ; 
PTRadioButton  RadioRegPoint ; 
PTRadioButton  RadioCheckMark; 
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public 


NewEntryDlgCls ( PTWindowsOb j ect  AParent , 
LPSTR  AName, 

long  X, 

long  Y); 

-NewEntryDlgCls ( ) ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Ok(RTMessage  Msg) 

virtual  void  Cancel (RTMessage  Msg] 


=  [ID_FIRST 
=  [ID_FIRST 


IDOK] ; 
IDCANCEL] 


NewFromEntryDlgCls 
Displays  new  from  entry  dialog  box. 


//  class 

// 

//  Purpose 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


class  NewFromEntryDlgCls  :  public  NewEntryDlgCls 
{ 


ivate : 

long 

FromX ; 

long 

FromY ; 

int 

Of f Azimuth, • 

long 

Of fDistance; 

PTEdit 

EditEast ; 

PTEdit 

EditNorth; 

PTEdit 

EditAzimuth; 

PTEdit 

EditDistance ; 

public 


NewFromEntryDlgCls ( PTWindowsOb j ect  AParent, 


LPSTR 

AName, 

long 

X, 

long 

Y, 

int 

Azimuth, 

long 

Distance) ; 

-NewFromEntryDlgCls ( ) ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Ok (RTMessage  Msg) 

=  [ID_FIRST  +  IDOK] ; 

virtual  void  Cancel (RTMessage  Msg) 

=  [ID_FIRST  +  IDCANCEL]; 

//  class 

// 

//  Purpose 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 


GunlnputDlgCls 
Displays  gun  input  dialog  box. 
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All  Rights  Reserved 


// 

class  GunlnputDlgCls  :  public  TDialog 

{ 
private : 


GunDBCls 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTComboBox 

PTComboBox 

PTComboBox 

PTComboBox 

PTBCheckBox 


aGun  ; 
EditEast; 
EditNorth; 
EditHeight; 
EditRange; 
EditLeft; 
EditRight; 
EditCommonDef ; 
Edi t Orient at ion ; 
ComboBattalion; 
ComboBattery ; 
ComboGun ; 
ComboGunType ; 
CheckMainGun ; 


public 


GunlnputDlgCls (PTWindowsObject  AParent, 
LPSTR  AName, 

long  X, 

long  Y) ; 

GunlnputDlgCls ( PTWindowsOb j  ect  AParent , 
LPSTR  AName , 

GunDBCls         Gun) ; 

-GunlnputDlgCls ( ) ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Ok(RTMessage  Msg)      =  [ID_FIRST 

virtual  void  Cancel (RTMessage  Msg)  =  [ID_FIRST 

virtual  void  Help (RTMessage  Msg)    =  [ID_FIRST 


IDOK] ; 
IDCAKCEL] 
IDHELP] ; 


//    class 

// 

//  Purpose   :  Displays  target  input  dialog  box. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


Target Input DlgCls 


class  TargetlnputDlgCls  :  public  TDialog 

{ 

private : 


TargetDBCls 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTEdit 

PTComboBox 


aTarget ; 

EditTargetNo; 

EditEast; 

EditNorth; 

EditHeight; 

EditDescription; 

ComboCategory ; 
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public 


Target Input DlgC Is (PTWindowsObject 

LPSTR 

long 

long 
Target InputDlgCls ( PTWindowsOb j  ect 

LPSTR 

TargetDBCls 
-TargetlnputDlgCls ( )  ; 
virtual  void  SetupWindow( ) ; 
virtual  void  Ok(RTMessage  Msg) 
virtual  void  Cancel (RTMessage  Msg) 
virtual  void  Help (RTMessage  Msg) 


AParent 

/ 

AName, 

X, 

Y)  ; 

AParent 

/ 

AName, 

Tar)  ; 

=  [ID_ 

FIRST 

+ 

IDOK] ; 

=  [ID_ 

FIRST 

+ 

IDCANCEL] 

=  [ID_ 

FIRST 

+ 

IDHELP] ; 

//========= 

//  class 

// 

//  Purpose 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


TargetDBDlgCls 
Displays  target  database  dialog  box, 


class  TargetDBDlgCls  :  public  TDialog 

{ 

private : 

PTListBox        ListNames; 
PTWindowsObject  MainWnd; 

public : 

TargetDBDlgCls ( PTWindowsOb j  ect  AParent , 

LPSTR  AName ) ; 

-TargetDBDlgCls ( ) ; 
virtual  void  SetupWindow( ) ; 
virtual  void  UpdateListBox( ) ; 
virtual  void  ButtonAdd (RTMessage)     = 
virtual  void  ButtonDelete (RTMessage)  = 
virtual  void  ButtonDetail (RTMessage)  = 
virtual  void  ButtonShow( RTMessage)    = 
virtual  void  Cancel (RTMessage)        = 
virtual  void  Help (RTMessage)  = 


[ID_FIRST 

+ 

ID_ADD] ; 

[ID_FIRST 

+ 

ID_DELETE] ; 

[ID_FIRST 

+ 

ID_DETAIL] ; 

[ ID_FIRST 

+ 

ID_SHOW] ; 

[ID_FIRST 

+ 

IDCANCEL] ; 

[ID_FIRST 

+ 

IDHELP] ; 

GunDBDlgCls 
Displays  gun  database  dialog  box, 


//  class 

// 

//  Purpose 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 
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class  GunDBDlgCls  :  public  TDialog 

{ 

private : 

PTListBox       ListNames; 
PTWindowsObject  MainWnd; 

public : 


GunDBDlgCls (PTWindowsObject  AParent, 

LPSTR  AName) ; 

-GunDBDlgCls () ; 
virtual  void  SetupWindow( ) ; 
virtual  void  UpdateListBox ( ) ; 
virtual  void  ButtonAdd (RTMessage) 
virtual  void  ButtonDelete (RTMessage) 
virtual  void  ButtonDetail (RTMessage) 
virtual  void  But tonShow (RTMessage) 
virtual  void  Cancel (RTMessage) 
virtual  void  Help (RTMessage) 


[ID_FIRST 

+ 

ID_ADD] ; 

[ID_FIRST 

+ 

ID_DELETE] ; 

[ID_FIRST 

+ 

ID_DETAIL] ; 

[ID_FIRST 

+ 

ID_SHOW] ; 

t ID_FIRST 

+ 

IDCANCEL] ; 

[ID_FIRST 

+ 

IDHELP] ; 

#endif    CHART  H 


Listing  B.3:  DEFINES.H  header  file 


//*********************•*********************•***************** 
// 

//  defines. h 

// 

//    header    file    for   defines 

//********•*******************************************•******* 


#ifndef     DEFINES_H 

#    define    DEFINES  H 


//menu  identifiers 

#define  CM_TRAININGMODE  101 

#define  CM_EXITCHART  109 

#define  CM_INSERT  203 

#define  CM_INSERTFROM  204 

#define  CM_GRIDSETUP  303 

#define  CM_TARGETSETUP  3  04 

#define  CM_GUNSETUP  3  05 

#define  CM_SAVEONEXIT  3  09 

#define  CM_DATABASETARGET  401 

#define  CM_DATABASEGUN  402 

#define  CM_ABOUT  151 
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//info  window  menu  identifiers 

#define  CM_SCALEONE  801 

#define  CM_SCALETWO  802 

#define  CM_SCALETHREE  803 

#define  CM_SCALEFOUR  804 

ttdefine  CM_SCALEFIVE  805 

#define  CM_SCALESIX  80  6 

//Grid  setup  dialog  window 

#define  ID_ZONE  112 

#define  ID_LEFT  10  5 

#define  ID_BOTTOM  10  6 

#define  ID_RIGHT  107 

#define  ID_T0P  108 

#define  ID_DISTANCE  2  04 

#define  ID_SCALE  110 

#define  ID_SHOWGRIDLINES  101 

#define  ID_SHOWNORTHSIGN  102 

//TargetSetupDlgCls  dialog  window 
#define  ID_SHOWTARGETS       110 

//GunSetupDlgCls  dialog  window 
#define  ID_SHOWGUNCOVERINGS  101 

//NewEntryDlgCls  dialog  window 

#define  ID_TARGET  101 

#define  ID_GUN  102 

#define  ID_RADAR  103 

#define  ID_OBSERVATIONPOST  104 

#define  ID_REGPOINT  105 

#define  ID_CHECKMARK  10  6 

//NewFromEntryDlgCls  dialog  window 

//it  uses  id_east,  id_north,  id_target,  id_gun,  id_others  as  well 

#define  ID_EAST  201 

#define  ID_NORTH  2  02 

#define  ID_AZIMUTH  203 

#define  ID_OFFDISTANCE       111 

//GunlnputDlgCls  dialog  window 

ttdefine  ID_MAINGUN  999 

ttdefine  ID_BATTERYNAME  10  0  0 

#define  ID_GUNNO  1001 

#define  ID_BATTALIONNAME  1002 

#define  ID_GUNTYPE  1005 

#define  ID_HEIGHT  1009 

#define  ID_MAXRANGE  1010 

#define  ID_MAXLEFT  1011 

#define  ID_MAXRIGHT  1012 

#define  ID_C0MM0NDEF  1013 

#define  ID_ORIENTATION  1014 

//TargetlnputDlgCls  dialog  window 
# define  ID_TARGETNO  103 

#define  ID_DESCRIPTION       107 
#define  ID_CATEGORY  108 

//TargetDBDlgCls  dialog  window 
#define  ID_NAMES  101 

#define  ID_ADD  102 


101 


#define  ID_DELETE 
#define  ID_DETAIL 
#define  ID  SHOW 
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#endif    DEFINES  H 


Listing  B.4:  GEN2LIST.H  header  file 


//***************************•*************************************** 

// 

//  gen21ist.h 

// 

//   header  file  for  the  template  classes 

//  genOdList 

//  genUdList 

//**************************•****************** 


#ifndef     _GEN2LIST_H 
#    define  _GEN2LIST_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#include  "abslist.h" 


II    template  struct 


template<class  T> 
struct  dListNode  { 

T  dataNode; 

dListNode<T>  *prevPtr; 

dListNode<T>  *nextPtr; 
}; 


dListNode 


//: 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 


template  class 
Purpose 


genOdList 


implements  a  classes  of  ordered  doubly-linked  lists 
with  the  following  operations  and  features: 

>  nodes  with  duplicate  keys  can  be  allowed. 

>  insert  new  node. 

>  search  for  a  node  with  a  specific  occurrence 
of  a  key . 

>  delete  a  node  with  a  specific  occurrence  of  a  key 

>  traverse  the  nodes  of  the  lists. 
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//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//======================================================: 

template<class  T> 

class  genOdList  :  public  genAbstractList<T> 

{ 

protected: 

dListNode<T>  *nodePtr,  //  node-visitation  pointer 

*tail,     //  pointer  to  the  tail  of  list 
*head;     //  pointer  to  head  of  list 
T  _bufl;     //  buffer 

genOdList<T>&  copy (genOdList<T>&) ; 

public : 

//state  manipulation  methods 
genOdList ( ) 
{  } 


genOdList (boolean  canoverwrite,  boolean  allowduplicate) ; 


genOdList (genOdList<T>&  dl) 
{ 

head  =  NULL;  copy(dl); 
} 


-genOdList ( 
{ 

clear ( ) ; 
} 


void  setNodePtr (dListNode<T>*  listPtr) ; 


void  setBufl(T&  newBufl] 
{ 

_bufl  =  newBufl; 
} 


//state  query  methods 
dListNode<T>*  getNodePtr() 
{ 

return  nodePtr; 
} 


//object  manipulation  methods 
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virtual  boolean  insert (T&) ; 

virtual  boolean  remove(T&  x,  unsigned  occur  =  1); 


virtual  boolean  search (T&  x,  unsigned  occur  =  1) 
{ 

dListNode<T>  *p; 
return  search(p,  x,  occur); 

} 


virtual  boolean  search (dListNode<T>*  &thisptr, 

T&  x, 

unsigned      occur  =  1); 

virtual  boolean  visitFirstNode (T&  x) ; 
boolean  visitPrevNode (T&  x)  ; 
virtual  boolean  visitNextNode (T&  x) ; 
boolean  visitLastNode (T&  x) ; 
virtual  void  clear() ; 


genOdList<T>&  operator  = (genOdList<T>&  dl) 

{ 

copy (dl) ; 

return  *this; 
} 


}; 


//    template  class               genUdList 

// 

//  Purpose  :  implements  a  classes  of  unordered  doubly-linked  lists 

//  with  the  following  operations  and  features: 

// 

//  >  nodes  with  duplicate  keys  can  be  allowed. 

//  >  insert  new  node. 

//  >  search  for  a  node  with  a  specific  occurrence 

//  of  a  key. 

//  >  delete  a  node  with  a  specific  occurrence  of  a  key. 

//  >  traverse  the  nodes  of  the  lists. 

// 

//  Notes  : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=================================================================: 

template-cclass  T> 

class  genUdList  :  public  genOdList<T> 

{ 

public : 

//state  manipulation  methods 
genUdList ()  {) 

genUdList (boolean  canoverwrite,  boolean  allowduplicate) 
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:genOdList<T> (canoverwrite,  allowduplicate) 
{  } 


genUdList (genUdList<T>&  dl) 

{ 

head  =  NULL;  copy(dl); 

} 


//object  manipulation  methods 

virtual  boolean  insert (T&)  ; 

virtual  boolean  search (dListNode<T>*  Scthisptr, 

T&  x, 

unsigned       occur  =  1); 


genUdList<T>&  operator  =  (genUdList<T>&  dl 

{ 

copy (dl) ; 

return  *this; 
} 


}; 


# end if   GEN2LIST_H 


Listing  B.5:  GLOBALS.H  header  file 


//it*****************************************-*******-*:*********-******** 
// 

//  globals.h 

// 

//  header  file  for  the  class  GlobalCls  and  varibals 


#ifndef     GLOBALS_H 

#    define  GLOBALS_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#define  FACTORSLIDE         250//the  bigger  the  slower 

II    class  GlobalsCls 

// 

//  Purpose   :  Holds  the  global  objects  and  variables  for  the  rest  of 
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// 
// 

//  Notes 

// 

//  Copyright 

// 


the  application. 


Copyright  (c)  1993,  Mustafa  ESER 
All  Rights  Reserved 


class  GlobalsCls 

{ 

public : 

long   WCLeft,  WCBottom;   //lower  left  most  coors  of  world 

long   VisibleWCLef t ;      //left-most  coordinate  of  screen 

long   VisibleWCBottom;    //bottom-most  coordinate  of  screen 

long   WCToRightExtension; // just  for  scroll  bars  limitations 

long   WCToTopExtension;   //just  for  scroll  bar  limitations 

int    Distances [5] ; 

int    CurrDistancelndex; 

short  DistancesCount ; 

long   Scales [6]  ; 

int    CurrScalelndex; 

short  ScalesCount ; 

BOOL   ShowGrids; 

BOOL   ShowNorthArrow; 

BOOL   ShowTargets; 

BOOL   ShowGunCoverings ; 

BOOL   SaveOnExit; 

int    MinScaleNDXForGuns; 

short  CurrBmpButtonSelection;  //tool  bar  bitmap  menu  selections 

long   SlideAmount.;  //scroll  bar  sliding  amount  in  meters 

//main  window  dimensions 
int    WidthMainWindow; 
int    HeightMainWindow; 


// 

GlobalsCls ( ) 
// 

{ 

Reset  (  )  ; 
} 


//. 
Res 
//. 
{ 


et() 


//firing  chart  extremum  coordinates 
WCLeft    =  10000; 
WCBottom  =  10000; 
VisibleWCLef t       =  WCLeft; 
VisibleWCBottom     =  WCBottom; 
WCToRightExtension  =  50000; 
WCToTopExtension    =  500  00; 


Distances [0]  =   100 

Distances [1]  =   500 

Distances [2]  =  1000 

Distances[3]  =  2000 

Distances [4]  -    5000 

CurrDistancelndex  =     2 
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DistancesCount 

= 

5; 

Scales [0] 

= 

2500 

Scales [1] 

= 

5000 

Scales[2] 

= 

12500 

Scales [3] 

= 

25000 

Scales [4] 

= 

50000 

Scales [5] 

= 

100000 

CurrScale Index 

= 

2 

ScalesCount 

= 

6 

ShowGrids 

= 

TRUE  ; 

ShowTargets 

= 

TRUE  ; 

ShowGunCoverings 

= 

TRUE  ; 

MinScaleNDXForGuns 

= 

1; 

ShowNorthArrow 

= 

TRUE  ; 

SaveOnExit 

= 

TRUE; 

CurrBmpButtonSelection  =  -1;  //means  none  of  them  is  selected 

SlideAmount         =  Scales [CurrScalelndex]  /  FACTORSLIDE; 
WidthMainWindow     =  800; 
HeightMainWindow    =  600; 


}; 


#endif    GLOBALS  H 


Listing  B.6:  GUNDB.H  header  file 


// 

//  gundb.h 

// 

//  header  file  for  the  class  GunDBCls 


#ifndef     _GUNDB_H 
#    define  _GUNDB_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#include  <string.h> 


#define  MAXNAMELEN    10 
#define  MAXMODELLEN   3  0 


_CLASSDEF ( GunDBC 1 s 
II    class 


GunDBCls 
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// 

//  Purpose   : Serves  as  database  management  class  for  gun  database 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//===============================================================: 

class  GunDBCls 

{ 

private : 


char 

char 

short 

long 

long 

int 

BOOL 

char 

long 

int 

int 

int 

int 


BattalionName[MAXNAMELEN] ; 

BatteryName[MAXNAMELEN] ; 

GunNo ; 

CoorEast ; 

CoorNorth; 

Height; 

MainGun; 

Model [MAXMODELLEN] ; 

MaxRange ; 

MaxRightDef lection; 

MaxLef t Deflect ion ; 

CommonOrientationDef lection , - 

Or ient at ionDe flection; 


public : 


// 

GunDBCls () 

// 

{ 

strcpy (BattalionName,  "*"); 

BatteryName[0]  =  NULL; 

GunNo  =  0 

CoorEast  =  0 

CoorNorth  =  0 

Height  =  0 

MainGun  =  0 
strcpy (Model,  "[-]'); 

MaxRange  =  0 

MaxRightDef lection  =  0 

MaxLef tDef lection  =  0 

CommonOrientationDef lection  =  0 

OrientationDef lection  =  0 


// 


GunDBCls (char* 

Btn, 

char* 

Btr, 

int 

Gun, 

long 

East, 

long 

North, 

int 

Height, 

BOOL 

mGun, 

char* 

Mod, 

long 

Range, 

int 

DefR, 

int 

DefL, 
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// 
{ 


int    CommonDef, 
int    Orientation) 


strcpy (BattalionName,  Btn) ; 

strcpy (BatteryName,  Btr) ; 

GunNo 

CoorEast 

CoorNorth 

Height 

MainGun 

strcpy (Model,  Mod); 

MaxRange 

MaxRightDe flection 

MaxLeft Deflect  ion 

CommonOri en tat ionDe flection 

OrientationDe flection 


Gun; 
East  ; 
North; 
Height ; 
mGun  ; 

Range ; 
DefR; 
DefL; 

CommonDef ; 
Orientation; 


// 

GunDBCls (const  GunDBClsk  T) 

// 

//copy  initializer 
{ 

strcpy (BattalionName,  T. BattalionName) ; 

strcpy (BatteryName,  T. BatteryName) ; 


GunNo 

CoorEast 

CoorNorth 

Height 

MainGun 

strcpy (Model ,  T. Model); 

MaxRange 

MaxRightDe flection 

MaxLeft Deflect ion 

CommonOrient at ionDe flection 

OrientationDe flection 


-  T. GunNo; 

=  T. CoorEast; 

=  T. CoorNorth; 

=  T.Height; 

=  T. MainGun  ; 

=  T. MaxRange; 

=  T.MaxRightDef lection ; 

=  T.MaxLeftDef lection; 

=  T.CommonOrientationDef lection; 

=  T.OrientationDef lection; 


// 

-GunDBCls ( 
// 

{} 


//assignment  operator 

/  / 

GunDBClsSc  operator  =  (const  GunDBCls  &T) 
// 

{ 


strcpy (BattalionName,  T. BattalionName 

strcpy (BatteryName,  T. BatteryName) ; 

GunNo 

CoorEast 

CoorNorth 

Height 

MainGun 


=  T. GunNo; 

=  T. CoorEast; 

=  T. CoorNorth; 

=  T.Height; 

=  T. MainGun  ; 
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strcpy (Model,  T. Model); 

MaxRange  =  T.MaxRange; 

MaxRightDef lection  =  T.MaxRightDef lection; 

MaxLeftDef lection  =  T.MaxLef tDef lection; 

CommonOrientationDef lection   =  T.CommonOrientationDef lection; 

OrientationDef lection  =  T.OrientationDef lection; 

return  *this; 


// 

int  operator  <   (GunDBCls&  aGun) 

// 

{ 

if(  strcmp (BattalionName,  aGun .Bat talionName)  <  0  )  { 

return  1 ; 
}else  if (strcmp (BattalionName,  aGun .BattalionName)  ==  0  )  { 
if (strcmp (BatteryName,  aGun. Bat teryName)  <  0  )  { 

return  1 ; 
}else  if (strcmp (BatteryName,  aGun .BatteryName)  ==  0  )  { 
i  f (  GunNo  <  aGun . GunNo  ) 
return  1 ; 
} 
} 
return  0; 

) 


// 

int  operator  >   (GunDBCls&  aGun) 

// 

{ 

if(  strcmp  (BattalionName,  aGun  .BattalionName)  >  0  )  { 

return  1 ; 
}else  if (strcmp (BattalionName,  aGun. BattalionName)  ==  0  )  { 
if (strcmp (BatteryName,  aGun .BatteryName)  >  0  )  { 

return  1 ; 
}else  if (strcmp (BatteryName,  aGun .BatteryName)  ==  0  )  { 
i  f (  GunNo  >  aGun . GunNo  ) 
return  1 ; 
} 
} 

return  0; 
} 


// 

int  operator  <=   (GunDBCls&  aGun) 

// 

{ 

if(  strcmp (BattalionName,  aGun .BattalionName)  <=    0  )  { 

return  1; 
)else  if (strcmp (BattalionName,  aGun. Bat talionName)  ==  0  )  { 
if (strcmp (BatteryName,  aGun. Bat teryName)  <=  0  )  { 

return  1 ; 
}else  if (strcmp (BatteryName,  aGun .BatteryName)  ==  0  )  { 
if (  GunNo  <=  aGun. GunNo  ) 
return  1 ; 
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} 

return  0 ; 


// 

int  operator  ==  (GunDBCls&  aGun) 

// 

{ 

if ( ! strcmp (BattalionName,  aGun .BattalionName) ) 
if ( ! strcmp (BatteryName,  aGun .BatteryName) ) 
if(GunNo  ==  aGun.GunNo) 
return  1; 
return  0 ; 


// functions  to  access  the 

char  *GetBattalionName ( ) 
char  *GetBatteryName ( ) 
short  GetGunNo ( ) 
long   GetCoorEast ( ) 
long   GetCoorNorth ( ) 
int    GetHeightO 
BOOL   isMainGun() 
char  *GetModel() 
long   GetMaxRange ( ) 
int    GetMaxRightDef lection (  ; 
int    GetMaxLeftDef lection ( ) 
int    GetCommonOrientationDef lection ( 
CommonOrientationDef lection; } 

int   GetOrientationDef lection ( ) 


data  members 
{return  BattalionName;} 
{return  BatteryName;} 
{return  GunNo;} 
{return  CoorEast;} 
{return  CoorNorth;} 
{return  Height;} 
{return  MainGun;} 
{return  Model;} 
{return  MaxRange;} 
{return  MaxRightDef lection; } 
{return  MaxLeftDef lection; } 
{return 

{return  OrientationDef lection; } 


// functions  to  set  the  data  member 

void  SetBattalionName (char  *in) 

void  SetBatteryName (char  *in) 

void  SetGunNo (short  in) 

void  SetCoorEast ( long  in) 

void  SetCoorNorth (long  in) 

void  SetHeight ( int  in) 

void  SetMainGun(BOOL  in) 

void  SetModel (char  *in) 

void  SetMaxRange ( long  in) 

void  SetMaxLef tDef lection (int  in) 

void  SetMaxRightDef lection ( int  in) 

void  SetCommonOrientationDef lection ( i 

{CommonOrientationDef lection  =  in; } 

void  SetOrientationDef lection ( int  in 

in;  } 


{strcpy (BattalionName,  in);} 
{strcpy (BatteryName,  in);} 
{GunNo  =  in;} 
{CoorEast  =  in; } 
{CoorNorth  -    in;} 
{Height  =  in; } 
{MainGun  =  in; } 
{strcpy (Model,  in);} 
{MaxRange  =  in;} 
{MaxLeftDef lection  =  in; } 
{MaxRightDef lection  =  in;} 
nt  in) 

{OrientationDef lection  = 


/  / 

void  Reset ( ) 
// 


//resets  all  data  members 
{ 
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BattalionNcune[0]  =  NULL; 

BatteryName[0]  =  NULL; 

GunNo  =  0 

CoorEast  =  0, 

CoorNorth  =  0 

Height  =  0 

MainGun  =  0 
strcpy (Model,  "[-]"); 

MaxRange  =  0 

MaxRightDef lection  =  0 

MaxLeftDef lection  =  0 

CommonOrientationDef lection   =  0 

OrientationDef lection  =  0, 


}; 


#endif   GUNDB  H 


Listing  B.7:  EVFO.H  header  file 


// 

//  info.h 

// 

//  header  file  for  the  classes  SelectionToolCls 

//  DistanceToolCls 

//  NewToolCls 

//  NewTToolCls 

//  SearchToolCls 

//  PickToolCls 

//  InfoWndCls 

//  ToolBarWndCls 

/ /  CanvasWndC 1 s 


#ifndef     INFO_H 

#    define  INFO_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#include  "chart. h" 


_CLASSDEF (SelectionToolCls) 

//===================================================: 

II    class  SelectionToolCls 

// 

//  Purpose   :  Base  class  for  selection  button  classes 

// 

//  Notes     : 
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// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 
//  All  Rights  Reserved 

class  SelectionToolCls 

{ 

protected: 

HCURSOR  hCursor; 

public : 

SelectionToolCls ( )  {} 

long  FindDistance ( long,  long,  long,  long); 
int   FindAzimuth( long,  long,  long,  long); 

//abstract  methods,  which  will  be  implemented  in  derived  classes 

virtual  void  DoMouseDown ( long,  long)   {) 

virtual  void  DoMouseMove (long,  long)   {} 

virtual  HCURSOR  GetCursor ( )  {return  hCursor;} 

virtual  void  Reset ( )  { ) 


_CLASSDEF(DistanceToolCls) 
//=============================================. 

II    class  DistanceToolCls 

// 

//  Purpose   :  Behaves  for  the  distance  button. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=============================================: 

class  DistanceToolCls  :  public  SelectionToolCls 

( 

private : 


BOOL     ClickedBefore; 

long     XI,  Yl; 

long     Distance; 

long     Azimuth; 

HCURSOR  hCursorl,  hCursor2 ; 


public 


DistanceToolCls (HCURSOR  hCl,  HCURSOR  hC2 ) ; 
virtual  void  DoMouseDown ( long  X,  long  Y) ; 
virtual  void  DoMouseMove ( long  X,  long  Y) ; 
virtual  HCURSOR  GetCursor () ; 
virtual  void  Reset () ; 


_CLASSDEF (NewToolCls) 

11=====================================: 

II    class  NewToolCls 

// 
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//  Purpose   :  Behaves  for  the  new  tool  button. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  NewToolCls  :  public  Select ionToolCls 

{ 

private : 

HCURSOR  hCursorl; 

public : 

NewToolCls (HCURSOR  hCl); 

virtual  void  DoMouseDown ( long  X,  long  Y) ; 

virtual  void  DoMouseMove (long  X,  long  Y) ; 

virtual  HCURSOR  GetCursor ( )  {return  hCursorl;} 

virtual  void  Reset ( ) ; 


_CLASSDEF(NewTToolCls) 

//================================================: 

II    class  NewTToolCls 

// 

//  Purpose   :  Behaves  for  the  new  from  tool  button, 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  NewTToolCls  :  public  SelectionToolCls 

{ 

private : 


BOOL     ClickedBefore; 

long     XI,  Yl; 

HCURSOR  hCursorl,  hCursor2; 

long     Distance; 

int      Azimuth; 


public 


NewTToolCls (HCURSOR  hCl,  HCURSOR  hC2 ) ; 
virtual  void  DoMouseDown (long  X,  long  Y) ; 
virtual  void  DoMouseMove ( long  X,  long  Y) ; 
virtual  HCURSOR  GetCursor () ; 
virtual  void  Reset ( ) ; 


_CLASSDEF(SearchToolCls) 

II    class  SearchToolCls 

// 

//  Purpose   :  Behaves  for  the  search  button 

// 
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//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  SearchToolCls  :  public  SelectionToolCls 

{ 
private : 

HCURSOR  hCursorl; 

public : 

SearchToolCls (HCURSOR  hCl); 

virtual  void  DoMouseDown ( long  X,  long  Y) ; 

virtual  void  DoMouseMove ( long  X,  long  Y) ; 

virtual  HCURSOR  GetCursor ( )  {return  hCursorl;} 

virtual  void  Reset ( ) ; 


_CLASSDEF(PickToolCls) 
//============================================= 

II    class  PickToolCls 

// 

//  Purpose   :  Behaves  for  the  pick  tool  button. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

11============================================= 

class  PickToolCls  :  public  SelectionToolCls 

{ 

private : 


HCURSOR  hCursorl, - 

public : 

PickToolCls (HCURSOR  hCl); 

virtual  void  DoMouseDown ( long  X,  long  Y) ; 

virtual  void  DoMouseMove ( long  X,  long  Y) ; 

virtual  HCURSOR  GetCursor ( )  {return  hCursorl;} 

virtual  void  Reset  (  ) ; 


_CLASSDEF ( Inf oWndCls ) 
//==============================================================: 

II    class  InfoWndCls 

// 

//  Purpose   :  Displays  the  info  area  at  the  bottom  of  the  window. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  199  3,  Mustafa  ESER 

//  All  Rights  Reserved 
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class  InfoWndCls  :  public  TWindow 

{ 

private : 

RECT         WndRect ; 
PTScrollBar  HorizantalScroll ; 

public : 


InfoWndCls (PTWindowsObject  AParent,  LPSTR  ATitle); 

-InfoWndCls () ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCT&) ; 

virtual  void  WMSize (TMessage&) ; 

virtual  void  WMLButtonDown (TMessage  &Msg)  =  [WM_FIRST  + 

WM_LBUTTONDOWN] ; 

virtual  void  MenuONE (RTMessage)  =  [CM_FIRST  + 
virtual  void  MenuTWO (RTMessage)  =  [CM_FIRST  + 
virtual  void  MenuTHREE( RTMessage)  =  [CM_FIRST  + 
virtual  void  MenuFOUR (RTMessage)  =  [CM_FIRST  + 
virtual  void  MenuFIVE (RTMessage)  =  [CM_FIRST  + 
virtual  void  MenuSIX (RTMessage)  -  [CM_FIRST  + 
virtual  void  WMHScroll (RTMessage  Msg); 
virtual  void  Display Info (char  *); 
virtual  void  DrawScaleButton ( ) ; 

}; 


CM_SCALEONE] ; 
CM_SCALETWO] ; 
CM_SCALETHREE] 
CM_SCALEFOUR] ; 
CM_SCALEFIVE] ; 
CM_SCALESIX] ; 


ToolBarWndCls 


_CLASSDEF(ToolBarWndCls) 
//======================== 

//  class 

// 

//  Purpose   :  Displays  the  tool  bar  area  at  the  right  of  the  window. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=================================================================; 

class  ToolBarWndCls  :  public  TWindow 

{ 

private : 


RECT 


WndRect; 


PTScrollBar       VerticalScroll ; 

HBITMAP  hBitmap[5]; 

HCURSOR  hCursorFrom,  hCursorTo,  hCursorPick; 

PSelectionToolCls  SelectionArray [5] ; 

public : 

ToolBarWndCls (PTWindowsObject  AParent,  LPSTR  ATitle); 
-ToolBarWndCls () ; 
virtual  void  SetupWindow( ) ; 

virtual  void  Paint (HDC  PaintDC,  PAINTSTRUCT&) ; 
virtual  void  WMSize  (TMessageSc)  ; 
virtual  void  WMVScroll (RTMessage  Msg) ; 

virtual  void  WMLButtonDown (TMessage  &Msg)  =  [WM_FIRST 
WM_LBUTTONDOWN] ; 
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CanvasWndCls 


}; 


_CLASSDEF (CanvasWndCls) 
//======================== 

//  class 

// 

//  Purpose   :  Displays  the  drawing  area  which  holds  targets,  gun 

//  positions  etc. 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 


class  CanvasWndCls  :  public  TWindow 

{ 

private : 

RECT     WndRect ; 
HBITMAP  TickMarkBmp; 
HBITMAP  TickMarkMask; 


public 


=  [WM_FIRST 
=  [WM  FIRST 


CanvasWndCls (PTWindowsObject  AParent,  LPSTR  ATitle) ; 

-CanvasWndCls ( ) ; 

virtual  LPSTR  GetClassName ( ) ; 

virtual  void  SetupWindow( ) ; 

virtual  void  Paint (  HDC  PaintDC,  PAINTSTRUCT&) ; 

virtual  void  WMLButtonDown (TMessage  &Msg)  =  [WM_FIRST 
WM_LBUTTONDOWN] ; 

virtual  void  WMMouseMove (TMessage  &Msg) 

virtual  void  WMSetCursor (TMessage  &Msg)    = 

virtual  BOOL  ReadTargetData ( ) ; 

virtual  BOOL  ReadGunData ( ) ; 

virtual  void  DisplayGuns (HDC  hDC) ; 

virtual  void  DisplayGunLabels (HDC) ; 

virtual  void  DrawGrids (HDC  hDC,  RECT  Rect) 

virtual  void  DisplayTargets (HDC  hDC) ; 

virtual  void  DisplayTargetLabels (HDC  hDC); 

virtual  void  DrawLocationLines ( long,  long) 

virtual  void  TestConstraints ( ) ; 
}; 


+  WM_MOUSEMOVE] 
+  WM_SETCURSOR] 


#endif 


INFO  H 


Listing  B.8:  TARGETDB.H  header  file 


****************************************************************** 


// 
// 
// 
// 

//  header  file  for  the  class  TargetDBCls 
//******************************************************************* 


targetdb.h 
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#ifndef     _TARGETDB_H 
#    define  _TARGETDB_H 

//note  that  the  following  code  is  executed  only 
//if  this  file  has  not  been  previously  included 


#include  <string.h> 


#de  f  ineMAXTARGETNOLENl 0 
#define  MAXCOORLEN       10 
#defineMAXDESLEN        50 
#defineMAXCATLEN        50 
#define  MAXBUF  50 


_CLASSDEF(TargetDBCls) 
//=================================================================== 

I /    class  TargetDBCls 

// 

//  Purpose   :  Serves  as  database  management  class  for  target  database 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//=================================================================== 

class  TargetDBCls 

{ 

private : 

char  TargetNofMAXTARGETNOLEN] ; 

long  CoorEast; 

long  CoorNorth; 

int  Height; 

char  Description [MAXDESLEN] ; 

char  Category [MAXCATLEN] ; 


public 


// 

TargetDBCls ( ) 

// 

{ 

TargetNo[0]      =  NULL; 
CoorEast         =  0, 
CoorNorth        =  0, 
Height  =  0, 

Description [0]   =  NULL; 
Category [0]      =  NULL; 


// 

TargetDBCls (char*  tn, 
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long   ea, 
long   no, 
int   he, 
char*  des, 
char*  cat) 


// 
{ 


strcpy (TargetNo,  tn)  ; 
CoorEast     =  ea; 
CoorNorth    =  no; 
Height       =  he; 
strcpy (Description,  des); 
strcpy (Category ,  cat); 


// 

TargetDBCls (const  TargetDBClsSc  T)  //copy  initializer 
// 

{ 

strcpy (TargetNo,  T. TargetNo ) ; 

CoorEast    =  T. CoorEast; 

CoorNorth   =  T. CoorNorth; 

Height      =  T.Height; 

strcpy (Description,  T. Description) ; 

strcpy (Category ,  T. Category ) ; 
} 


// 

-TargetDBCls ( ) 
// 

{} 


// 

TargetDBClsSc  operator  =  (const  TargetDBCls  &T) 
// 

//assignment  operator 

< 

strcpy (TargetNo,  T .TargetNo) ; 

CoorEast        =  T. CoorEast; 
CoorNorth       =  T. CoorNorth; 
Height  =  T.Height; 

strcpy (Description,  T. Description) ; 
strcpy (Category ,  T. Category ) ; 
return  *this; 
} 


// 

int  operator  <   (TargetDBClsSc  aTarget 
// 

{ 


} 


return  strcmp (GetTargetNo ( ) ,  aTarget .GetTargetNo () )  <  0; 
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// 

int  operator  >   (TargetDBClsSc  aTarget) 

// 

{ 

return  strcmp (GetTargetNo ()  ,  aTarget .GetTargetNo () )  >  0 ; 


// 

int  operator  <=   (TargetDBClsSc  aTarget 
// 

{ 


} 


return  strcmp (GetTargetNo () ,  aTarget .GetTargetNo () )  <=  0; 


// 

int  operator  ==  (TargetDBClsSc  aTarget) 
// 

{ 

} 


return  strcmp (GetTargetNo () ,  aTarget .GetTargetNo () )  ==  0; 


// functions  to  access  the  data  members 

char*  GetTargetNo ( )   {return  TargetNo;} 
long   GetCoorEast ( )       {return  CoorEast;} 
long   GetCoorNorth ( )    {return  CoorNorth; } 
int    GetHeight ( )    {return  Height;} 
char*  GetDescription ( )   {return  Description;} 
char*  GetCategory ( )    {return  Category;} 

// functions  to  set  the  data  members 

void  SetTargetNo (char*  tn)      {strcpy (TargetNo,  tn) ; } 

void  SetCoorEast ( long  east)   {CoorEast  =  east;} 

void  SetCoorNorth ( long  north)   {CoorNorth  =  north;} 

void  SetHeight ( int  height)    {Height  =  height;} 

void  SetDescription (char*  des)  {strcpy (Description,  des) 

void  SetCategory (char*  cat)   {strcpy (Category ,  cat);} 


// 

void  Reset ( ) 
// 

{ 


=  NULL; 


TargetNo [0] 
CoorEast      =  0; 
CoorNorth       =  0 ; 
Height  =  0; 

Description [0]  =  NULL; 
Category [0]     =  NULL; 


}; 


# end if   TARGETDB  H 
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APPENDIX  C.  (DATABASE  HEADER  FILES  LISTINGS) 

Listing  CI:  DBGUN.H  header  file 

//********************•**************•*****•****************** 
// 

/ /  dbgun . h 

// 

//  header  file  for  the  class  DBGunCls 

//********************•*********************************** 


#ifndef     _DBGUN_H 
#    define   DBGUN  H 


#include  "WStr.h" 

# include  " Paradox. h" 


#define  MAXNAMELEN    10 
#define  MAXMODELLEN   3  0 


_CLASSDEF ( DBGunC 1 s ) 

II    class  DBGunCls 


Performs  database  management  for  guns 


// 

//  Purpose 

//  Notes 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//============================================; 

class  DBGunCls 

{ 

private : 

//#1 

char  Battal ionName [MAXNAMELEN] ; 

char  BatteryName [MAXNAMELEN] ; 

short  GunNo ; 

long  CoorEast ; 

long  CoorNorth; 

int  Height; 

BOOL  MainGun; 

char  Model [MAXMODELLEN] ; 

long  MaxRange; 

int  MaxRightDef lection; 

int  MaxLeftDef lection; 

int  CommonOrientationDef lection; 

int  OrientationDef lection; 

char  FiringTableName [MAXNAMELEN] ; 

//#14 

//Paradox  table  info 
ParadoxTable  TableGuns; 
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int 

nFields; 

LPSTR 

Names [14] ; 

LPSTR 

Types [14] ; 

protected: 

void  RecordToBuf f er ( ) ; 

public : 

DBGunC Is (LPSTR  TableName) ; 
-DBGunClsO  ; 

BOOL  ReadFirst ( ) ; 
BOOL  ReadLastO 
BOOL  ReadNext ( ) 
BOOL  ReadPrev() 
BOOL  isTableEmpty ( ) ; 
BOOL  isLast ( ) ; 


BOOL  AddRecord ( ) ; 

BOOL  UpdateRecord( ) ; 

BOOL  DeleteRecord( ) ; 

BOOL  SearchByKey (char  *Btn,  char  *Btr,  int  Gun); 

void  Reset ( ) ; 

//functions  to  access  the  data  members 


int    GetMaxLeftDef lection ( 


return  BattalionName; } 
strcpy (BattalionName,  in);} 

return  BatteryName; } 
strcpy (Bat teryName,  in);) 

return  GunNo; ] 
GunNo  =  in;} 

return  CoorEast;} 
CoorEast  =  in; } 

return  CoorNorth; } 
CoorNorth  '=  in;} 


char  *GetBattalionName ( ) 

void  SetBattalio.nName  (char  *in; 

char  *Get Bat teryName ( ) 

void  SetBatteryName (char  *in) 

short  GetGunNo ( ) 

void  SetGunNo (short  in) 

long  GetCoorEast ( ) 

void  SetCoorEast ( long  in) 

long  GetCoorNorth ( ) 

void  SetCoorNorth ( long  in) 

int  GetHeightO 

void  SetHeight ( int  in) 

BOOL  isMainGun ( ) 

void  SetMainGun(BOOL  in) 

char  *GetModel() 

void  SetModel (char  *in) 

long  GetMaxRange ( ) 

void  SetMaxRange ( long  in) 

int  GetMaxRightDef lection ( ) 

void  SetMaxLef tDef lection (int  in) {MaxLeftDef lection  =  in;} 


return  Height;} 
Height  =  in; } 

return  MainGun;} 
MainGun  =  in; } 

return  Model;} 
strcpy (Model,  in);} 

return  MaxRange;} 
MaxRange  =  in; } 

return  MaxRightDef lection; } 


return  MaxLeftDef lection; } 


void   SetMaxRightDef lection ( int  in) (MaxRightDef lection  =  in;} 


122 


int    GetCommonOrientation ( ) 

{return  CommonOrientationDef lection; } 
void   SetCommonOrientation ( int  in) 

{CommonOrientationDef lection  =  in; } 

int   GetOrientationDef lection ( )        {return  OrientationDef lection; } 
void   SetOrientationDef lection ( int  in)  {OrientationDef lection  =  in;} 

char  *GetFiringTableName ( )  {return  FiringTableName; } 

void   SetFiringTableName (char  *fn)      {strcpy (FiringTableName,  fn);} 

}; 

#endif   DBGUN  H 


Listing  C.2:  DBTARGET.H  header  file 


//••it**************************************** 
// 

//  dbtarget.h 

// 

//  header  file  for  the  class  DBTargetCls 

//******************************•******•*************************** 


ttifndef     _DBTARGET_H 
#    define   DBTARGET  H 


# include  "WStr.h" 

# include  " Paradox. h" 


#define  SUCCESS  1 

#define  FAIL  0 
#define  MAXTARGETNOLEN   10 

#define  MAXCOORLEN  10 

#define  MAXDESLEN  50 

#define  MAXCATLEN  50 

#define  MAXBUF  50 


_CLASSDEF (DBTargetCls) 

II    class  DBTargetCls 

// 


Performs  database  management  for  targets 


//  Purpose 

//  Notes 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//============================================; 

class  DBTargetCls 

{ 

private : 
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char    TargetNo [MAXTARGETNOLEN] ; 

double  CoorEast; 

double  CoorNorth; 

double  Height; 

char    Description [MAXDESLEN] ; 

char    Category [MAXCATLEN] ; 

//Paradox  table  info 
ParadoxTable  TableTargets; 
int  nFields; 

LPSTR  Names [6]; 

LPSTR  Types [6]; 

protected: 

void  RecordToBuf f er ( ) ; 
void  Buf f erToRecord( ) ; 


public : 

DBTargetCls (LPSTR  TableName; 
-DBTargetCls ( )  ; 

BOOL  ReadFirst ( ) ; 
BOOL  ReadLast ( ) 
BOOL  ReadNext ( ) 
BOOL  ReadPrev( ) 
BOOL  isTableEmpty ( ) ; 
BOOL  isLast ( ) ; 

BOOL  AddRecord ( ) ; 

BOOL  UpdateRecord( ) ; 

BOOL  DeleteRecord( ) ; 

BOOL  SearchByKey (char  *Key) ; 

void  Reset ( ) ; 

char   *GetTargetNo ( )  {return  TargetNo; } 

void    SetTargetNo(char*  tn)    {strcpy (TargetNo,  tn) ; } 

double  GetCoorEast ( )  {return  CoorEast;} 

void    SetCoorEast (double  east ) {CoorEast  =  east;} 

double  GetCoorNorth ( )  {return  CoorNorth;} 

void    SetCoorNorth( double  north) {CoorNorth  =  north;} 

double  GetHeightO  {return  Height;} 

void    SetHeight (double  height ) {Height  =  height;} 

char   *GetDescription ( )  {return  Description;} 

void    SetDescription (char*  des)  {strcpy (Description,  des);} 

char   *GetCategory ( )  {return  Category;} 

void    SetCategory (char*  cat)   {strcpy (Category ,  cat);} 
}; 

#endif   DBTARGET  H 
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Listing  C.3:  DBTBLF.H  header  file 


// 

//  dbtbl_f.h 

// 

//  header  file  for  the  clas  DBTable_F_Cls 


#ifndef     DBTABLE_F_H 

#    define    DBTABLE  F  H 


#include  "WStr.h" 

# include  " Paradox. h" 


_CLASSDEF(DBTable_F_Cls) 

II    class 

// 


DBTable  F  Cls 


//  Purpose 

//  Notes 

//  Copyright 

// 


Performs  database  management  for  Table  F  of  firing  table 

Copyright  (c)  1993,  Mustafa  ESER 
All  Rights  Reserved 


class  DBTable_F_Cls 

{ 
private : 

double  Range; 
double  Elevation; 
double  FSforGrazeBurst ; 
double  DFSperlOmDecHOB; 
double  DRperlmilDElev; 
double  Fork; 
double  TimeOf Flight ; 
double  AzimuthCorrDrif t ; 
double  AzimuthCorrCrossWind 
double  MuzzleVelocityDec; 
double  MuzzleVelocitylnc; 
double  RangeWindHead; 
double  RangeWindTail ; 
double  AirTempDec; 
double  AirTempInc; 
double  AirDensityDec; 
double  AirDensitylnc; 
double  ProjectileWeightDec; 
double  ProjectileWeightlnc; 


I/O 
III 
1/2 
1 12 
1/4 
l/S 

lie 

I II 
118 
119 
I  /10 
I  111 
1 112 
I  /13 
//14 
I  IIS 
I  lie 
I  111 
1118 


//Paradox  table  info 
ParadoxTable  Table_F; 
int  nFields; 

LPSTR  Names [18] 

LPSTR  Types [19] 
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protected: 

void  RecordToBuf fer ( ) ; 

public: 

DBTable_F_Cls(LPSTR  TableName) ; 
~DBTable_F_Cls ( ) ; 

BOOL  ReadFirst ( ) ; 
BOOL  ReadLast ( ) 
BOOL  ReadNext ( ) 
BOOL  ReadPrev() 
BOOL  isTableEmpty ( ) ; 
BOOL  isLast ( ) ; 

void  Reset ( ) ; 

double  FindElevat ion (double  range) ; 
}; 


# end if    DBTABLE  F  H 


Listing  C.4:  PARADOX.H  header  file 


//*****************  *  *  ************************************************ 
// 

/  /  paradox . h 

// 

//  header  file  for  database  engine  inclusions 

//it*************************************** 


#ifndef  PARADOX_H 

#    define  PARADOX  H 


#  include  <alloc.h> 

#  include  <string.h> 

#  include  "PdoxEnging .h" 

#  include  "PdoxTable .h" 

#  include  "PdoxRecord.h" 


//  Note  the  following  code  is  only  executed  if 
//  this  file  has  not  been  previously  included 


char  *GetParadoxError  ( int  nError) ; 


#endif 
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Listing  C.5:  PDOXENG.H  header  file 


/J******************************************************************* 
// 

/ /  pdoxeng . h 

// 

//  header  file  for  the  class  Select ionWndCls 


#ifndef     ParadoxEngine_H 
#    define  ParadoxEngine_H 

//  Note  the  following  code  is  only  executed  if 
//  this  file  has  not  been  previously  included 


#include  "pxengine.h" 

#ifdef  BORLANDC 

//PC  computer  specific  includes 
#    include  <owl.h> 
#endif 


#ifdef  Unix 

//  Unix  computer  specific  includes 
#endif 


II    class  ParadoxEngine 

// 

//  Purpose   : 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

//============================================: 

_CLASSDEF  (ParadoxEngine) 

class  ParadoxEngine 

{ 

public : 

static  Status; 

ParadoxEngine  (LPSTR  szAPlication) ; 
~ParadoxEngine  (); 
}; 


#endif  ParadoxEngine_H 
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Listing  C.6:  PDOXREC.H  header  file 


// 

//  pdoxrec.h 

// 

//  header  file  for  the  class  ParadoxRecord 


#ifndef     ParadoxRecord_H 
#    define  ParadoxRecord_H 

//  Note  the  following  code  is  only  executed  if 
//  this  file  has  not  been  previously  included 


#include  <ctype.h> 
#include  "PxEngine.h" 
#include  "WStr.h" 


#ifdef  BORLANDC 

//  PC  computer  specific  includes 

#include  <owl.h> 

#endif 


#ifdef  Unix 

//  Unix  computer  specific  includes 

#endif 


_CLASSDEF  (ParadoxTable) 
_CLASSDEF  ( ParadoxRecord ) 

//============================================: 

II    class  ParadoxRecord 

// 

//  Purpose   : 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  ParadoxRecord 

{ 

private : 

ParadoxTable  ParentTable; 
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public : 


RECORDHANDLE  HRecord; 
intStatus; 

ParadoxRecord  (ParadoxTable); 
virtual  -ParadoxRecord  ( ) ; 

void  RawGet  (void  *,  int  Buf ferSize) ; 
void  RaPut  (void  *,  int  Buf ferSize) ; 

WStr  GetField  (FIELDHANDLE  FieldNumber) ; 

WStr  GetField  (LPSTR  FieldName); 

void  PutField  (FIELDHANDLE  FieldNumber,  WStr); 

void  PutField  (LPSTR  FieldName,  WStr) ; 

int  Update  ( ) ; 
int  Add  ( ) ; 
int  Read  ( ) ; 


# include  "PdoxTable .h" 


#endif  ParadoxRecord  H 


Listing  C.7:  PDOXTAB.H  header  file 

// 

//  Pdoxtab.h 

// 

//  header  file  for  the  class  ParadoxTable 


#ifndef     ParadoxTable_H 
#    define  ParadoxTable_H 

//  Note  the  following  code  is  only  executed  if 
//  this  file  has  not  been  previously  included 


#include  <DIR.H> 
#include  "WStr.h" 
#include  "pxengine.h" 
# include  "PdoxEngine .h" 
#include  "PdoxRecord.h" 


#ifdef    BORLANDC 
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//  PC  computer  specific  includes 

#include<owl .h> 

#endif 


#ifdef  Unix 

//  Unix  computer  specific  includes 

#endif 


_CLASSDEF  (ParadoxTable) 

//  class  ParadoxTable 

// 

//  Purpose   : 

// 

//  Notes     : 

// 

//  Copyright:  Copyright  (c)  1993,  Mustafa  ESER 

//  All  Rights  Reserved 

class  ParadoxTable 

{ 

public : 


}; 


intStatus; 

ParadoxRecord  Record; 
TABLEHANDLE      HTable; 

ParadoxTable  (LPSTR   TableName, 

int     IndexField  =  0, 

int     nFields  =  0, 

char   *Names [ ]  =  NULL, 

char   *Types[]  =  NULL) ; 
virtual  -ParadoxTable  ( ) ; 

void  DeleteAll  ( ) ; 

RECORDNUMBER  TotalRecords  ( ) ; 
RECORDNUMBER  CurrentRecord  ( ) ; 

void  RecordUpdate  ( ) ; 
void  RecordDelete  ( ) ; 
void  RecordAdd  ( ) ; 

void  ReadFirst  ( ) ; 

void  ReadLast  ( ) ; 

void  ReadNext  ( ) ; 

void  ReadPrev  ( ) • 

void  ReadRecord  (RECORDNUMBER  RecordNumber ) ; 

void  IndexDelete  (char  *Field) ; 

void  IndexDelete  (FIELDHANDLE  FieldNumber) ; 

void  IndexAdd  (char  *Field,  int  Mode  =  INCSECONDARY) ; 

void  IndexAdd  (FIELDHANDLE  FieldNumber,  int  Mode  =  INCSECONDARY) ; 

void  Find  (WStr  Match,  LPSTR  FieldName,  int  Mode  =  SEARCHFIRST) ; 
void  Find  (WStr  Match,  FIELDHANDLE  FieldNumber,  int  Mode  =  SEARCHFIRST) 
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#endif    ParadoxTable_H 
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APPENDIX  D.  (SCREENS  OF  APPLICATIONS) 
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Screen  4:  (OFire)  Call  for  fire  dialog  box. 
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Screen  5:  (OFire)  Fire  order  dialog  box. 
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Screen  6:  (OFire)  Message  to  observer  dialog  box. 
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Screen  7:  (OFire)  Subsequent  fire  call  dialog  box. 
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Screen  8:  (OFire)  Time-on-target  dialog  boxes.  The  above  dialog  box  set  the  time  refering  the 
present  time,  while  the  below  one  sets  the  exact  time. 


139 


<9S 


-   ill 

;  ,TflT 

j< 

: 

c 


1 

9> 


1 
I 


§11 


140 


Screen  10:  (OChart)  Grid  setup  dialog  box. 
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Screen  11:  (OChart)  Both  tartget  and  guns  database  dialog  boxes. 
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Screen  12:  (OChart)  Target  display  setup  dialog  box. 
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Screen  13:  (OChart)  Gun  display  setup  dialog  box. 
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Screen  14:  (OChart)  Input  inquiry  dialog  box. 
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Screen  15:  (OChart)  Input  inquiry  dialog  box  (refering  to  a  point) 
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Screen  16:  (OChart)  Target  input  dialog  box. 
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Screen  17:  Azimuth  and  distance  distance  display  dialog  box. 
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Screen  18:  (OChart)  Gun  input  dialog  box. 
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